ODYSSEY Interim Service Integrator

Description

Summary of the work The ODYSSEY Programme within Defence Digital requires an Interim Service Integrator (ISI) to be its Technical Delivery Partner, providing Scaled Agile Framework (SAFe) System Development and scalable DevSecOps delivery Teams. As a Technical Delivery Partner, the ISI will help shape and direct the present and future solution of the System. Expected Contract Length 24 months + 6 months optional extension Latest start date Monday 2 August 2021 Budget Range It is estimated that the work can be delivered over 24 months, within the core budget range of £3.95M - £6.33M ex VAT, with an additional Limit of Liability (LoL) of up to £3.15M. LOL’s are in place for any potential additional licencing or tasking requirements. Why the Work is Being Done The ODYSSEY Programme is responding to an increasing demand to transform the way that Users access and visualise disparate data through core enterprise services. The Programme now requires an Interim Service Integrator (ISI) to incrementally develop and build upon the existing Alpha System, delivering enhancements through Agile Product Delivery in a highly regulated environment. Problem to Be Solved Driven by specific use cases and a customer owned backlog, ODYSSEY requires an ISI to incrementally design and develop the existing Alpha data platform to a Beta level of maturity and subsequent Agile Product Delivery, providing an early but exploitable capability to the end user. The focus is on the exploitation of data, leveraging new ways of working, advanced data science, and subsets of Artificial Intelligence (AI), such as Automation and Machine Learning (ML) applications to “augment the Analyst” by increasingly automating elements of the day-job. The system will be developed in line with MOD and HMG frameworks, policies and standards in order to achieve compliance. To respond to the increasing development requirements the ISI is required to provide a scalable and flexible core team of resources at pace to meet the delivery demands of the Programme. The Programme has adopted the SAFe methodology and requires the ISI to lead, implement and manage the 'Essential' SAFe configuration construct to ensure the successful delivery of the business solutions. Who Are the Users As an Analyst I need to better search, visualisation, analysis, production, collaboration and dissemination of curated data and reports more effectively and efficiently. As a Decision Maker I need to effectively and efficiently enhance my decision making. As a Technical Delivery Team member of a Data System I need a well-documented, compliant and managed System, which can be developed incrementally and deployed quickly. Early Market Engagement N/A Work Already Done ODYSSEY has developed an Alpha System that has key functionality at its core. This has been an ongoing development activity with the latest release due mid-2021. To date, research has been undertaken with an Industry Partner and DSTL which supports and places the Programme's requirements in a well-informed position going forward. Existing Team MOD Programme Team – (Enterprise Architecture, Engineering and PM Civil Servants, plus a User Representative). The Design Authority (DA) – will set the Enterprise policy, standards and direction to which the Programme will comply. Current Phase Alpha Skills & Experience • NOTE: THIS SECTION AS A WHOLE IS WORTH 10%. • Experience as a service integrator/developer of coordinating, facilitating, leading and managing, cadence-based formalities such as planning events, sprints and daily stand-ups. • Demonstrate experience in agile DevSecOps services providing engineering and development expertise with technical skills > 3 years. • Experience in delivering high quality Application Programming Interface (API), services and applications to a highly secured and regulated standard. • Demonstrable experience of implementing and managing cloud environments (such as AWS and Azure) for large microservice architectures. • Demonstrable experience of developing Artificial Intelligence applications, focusing on Automation, Natural Language Processing (NLP) and Machine Learning (ML). • Evidence of producing and maintaining key design and security artefacts to a highly regulated standard, at pace and within tight timescales. • Demonstrable experience of developing Knowledge Graphs and Ontologies. • Demonstrable experience in the integration of disparate and open source data sources, by way of control, consumption, curation and exploitation of data. Nice to Haves • NOTE: THIS SECTION AS A WHOLE IS WORTH 5%. • Experience of developing across a range of Security Classifications. • Demonstrable experience and knowledge of Object Based Production (OBP) and Structured Observation Management (SOM) • Demonstrable experience of implementing SAFe for System development. • Demonstrable experience in implementing one or more of the following: Apache Airflow, Swagger, Helm Charts, Pattern Recognition and Link Prediction. • Demonstrable experience of delivering scalable and resilient search, visualisation tools and data analytics through a high-quality UI, front end and an interactive UX. • Proven track record in defining/implementing test strategies/plans in agile environments, with a high degree of automation and the resolution of issues, including security vulnerabilities and the remediation techniques used. • Demonstrate experience in using JavaScript, Github, Jenkins, Kubernetes, Python, database techniques for Data manipulation. Work Location The Supplier is to provide a List X premises for their team. There is the possibility that the Supplier will need to travel to multiple MoD sites, as conditions allow, predominately MoD Abbey Wood South, Bristol, BS34 8JH, but also: (i) MoD Corsham, Corsham, SN13 9GB (ii) PJHQ Northwood, Northwood, HA6 3EZ (iii) DSTL Porton Down, Salisbury, SP4 0JQ (iv) Ad Hoc UK locations as required. Working Arrangments The supplier will be required to facilitate collaborative, face to face planning events at their premises, with capacity to host the buyer. Additional collaborative engagement should be conducted via Microsoft Teams (or suitable equivalent) accessible from the Buyer networks). Security Clearance It will be expected that the Team Leader be Developed Vetting (DV) cleared with the rest of the delivery team to hold Security Check (SC) as a minimum. Suppliers must have the relevant clearances in place for contract start date. The authority will not hold or sponsor clearances. Additional T&Cs ODYSSEY will be competing for an Intelligent Customer Team in parallel to the ISI. Suppliers may bid for both the ICT and ISI contracts. To ensure independence of outputs a supplier cannot “win” both. Suppliers bidding for both contracts must indicate a preference which will not influence the scoring. The ultimate decision is with the buyer. A bidder’s conference for the short-listed suppliers will be held and they will be supplied with a Statement of Requirement against which to produce their technical proposal. The Cyber Risk Profile has been identified as HIGH. DEFCON 703 applies to this contract. No. of Suppliers to Evaluate 5 Proposal Criteria • Describe how the proposed solution will be successfully implemented, including the approach and methodology, to deliver the core requirements and deliverables, as detailed in questions 2 and 3 below): • • (1) Design, development and integration (8%). (2) System Management and Support (4%). (3) Security, Policy and Requirements (7%). • • (4) Test, Evaluation and Acceptance Requirements (4%). (5) Safety and Environmental, Training and Exit Management (3%). (6) Agile Planning, Governance and Delivery (5%). • Describe how you will successfully implement the Essential SAFe configuration constructs to meet the programme’s objectives (4%) • Describe how you will work as part of an integrated, yet geographically distributed, team. (3%) • Describe how you will scale up DevSecOps teams and Shared Services (specialist roles, people and services) quickly to meet customer demand. (4%) • Explain how your proposed solution provides the MOD Value for money. (2%) • Describe how you will work with and explain complex technical issues to clients with low technical expertise. (4%) • Describe your proposed team structure including but not limited to the roles, responsibilities, ways of working and location (2%) Cultural Fit Criteria • Describe how you will adopt and implement (10%): (1)The Lean Agile Mindset. (2)Concepts of the Agile Manifesto. (3)The SAFe Core Values. (4)A Continuous Learning Culture. (5)Knowledge Transfer . • In response to changing requirements and uncertainty, describe how you will effectively and positively, deliver change through effective collaboration and leadership. (5%) Payment Approach Fixed price Evaluation Weighting Technical competence 65% Cultural fit 15% Price 20% Questions from Suppliers 1. Noting the statement “Suppliers may bid for both contract, however, to ensure independence of the outputs, a supplier cannot ‘win’ both”It would be useful to understand if the statement refers only to the ability to prime both contracts, or, if indeed refers to the wider construct of a proposed supply chain.As an example, please confirm if the following acceptable:A)Bidder A prime ISI with Bidder B as sub-contractorB)Bidder C prime ICT with Bidder B as sub-contractorA)Bidder X prime ISI with Bidder Y as sub-contractorB)Bidder Y prime ISI with Bidder X as sub-contractor Yes the statement only applies to the Prime Contractor, how the sub-contractor teams are formulated are up to the individual Companies, with only a few caveats:- The same person or team cannot work on both contracts. So if a person/team is part of the ISI, the person/team from the same company who may be on the ICT contract must be different, and have the correct firewalls in place to ensure, as standard with MoD contracts, that information from 1 contract does not flow into the other contract. 2. Is there an incumbent supplier for this? No. 3. Will you be releasing the Security Aspects Letter (SAL) for ODYSSEY as part of the ITT? Yes this will be released to the down selected companies with the rest of the ITT and draft contract documentation. 4. Who is the current incumbent? ***CQ2 was answered incorrectly. This is the correct answer to the questions regarding current incumbent***Montvieux is the incumbent industry partner. There will be no industry partner between June and the start of this contract and thus no transition period. 5. Is there an incumbent supplier for this? Montvieux is the incumbent industry partner. There will be no industry partner between June and the start of this contract and thus no transition period. 6. With relation to the work that has already been undertaken, can you confirm what technology the Alpha System is based on and would you be taking this forward as a preferred platform for continued developments? The advert is indicative of the technologies in use by the Alpha System. Further information will be made available at the next stage. The adoption of the Alpha System is the assumed starting point, with the expectation that the system will evolve with the support of the supplier through innovation. 7. Who is your Industry Partner? Montvieux is the incumbent industry partner. There will be no industry partner between June and the start of this contract and thus no transition period. 8. It appears that you are attempting to develop the capability to meet your ultimate requirements. We have a platform that we believe delivers this capability as a COTS product (therefore negating the time and cost of developing such a platform) which allows you to quickly move to data analysis and meeting your ultimate objectives without a heavy development cycle. It is open and flexible and does not restrict development, however we feel a significant cost saving could be gained by reviewing our product capability first. Please can you confirm how such suppliers may approach you for consideration. The current strategy for this this next 2 year phase of work is to build upon a MOD developed Alpha and retaining IPR. 9. Can the authority please confirm who undertook the discovery phase? Dstl and Montvieux 10. Please can you confirm what products have been used for the Alpha System and if you be taking these products forward for continued development? The advert is indicative of the technologies in use by the Alpha System. Further information will be made available at the next stage. The adoption of the Alpha System is the assumed starting point, with the expectation that the system will evolve with the support of the supplier through innovation. 11. In both the Essential and Nice to Have sections, there is an initial box to write 100 words in but no steer on what to write. Is this a mistake in the form, or is there an expectation to write an introduction for example in each section? Please respond N/A to this question. This was to ensure we could provide detail of the weighting of the section. 12. Does the Authority require the supplier to provide their own cyber security / protective monitoring / security logging for the Alpha and Beta systems / environments? There will be a collaborative approach to security, monitoring and logging requirements in addition to those provided by the core enterprise services 13. Can the Authority please confirm if all the work done to date has been done at DCPP high? All work done to date has been completed at the appropriate level. 14. Will a list of assets, models and designs be part of contract take-on to support a validation of the baseline architecture? Yes 15. Has the Authority established the approach for how the organisations who are successful in the two DOS opportunities will ensure a clear, documented and effective way of working? For example what is the primary touch points between backlog management and customer centric design thinking in the ISI and the architecture and requirements work, and specifically how are user requirements captured and curated? The ICT and ISI suppliers will be expected to work alongside each other. The communication approach has been outlined but will be agreed once both suppliers have been placed on contract. 16. Grateful if the Authority could provide bidders with an indication on to what degree the move from Alpha to Beta is fundamentally transformative, gently iterative or somewhere in between, and what role the current backlog plays in steering that? The supplier is required to implement and manage the 'Essential' SAFe configuration construct. Further information on current capability and future direction will be provided in the SoRs for the down selected suppliers. 17. Can the Authority please provide an estimate of the size of the current backlog; specifically is the Authority able to provide the number of stories (or other metric used during Alpha development) and associated resource hours (alongside an average velocity)? The alpha prototype will be provided as gfx at the start of the contract. The supplier will be required to manage a new backlog with the authority. Further information on current capability and future direction will be provided in the SoRs for the down selected suppliers. 18. Appreciate if the Authority could provide the data on whether the backlog has been growing or shrinking, and whether the sprint velocity has been increasing or reducing, during the Alpha stage? Further information on current capability and future direction will be provided in the SoRs for the down selected suppliers. 19. The ISI listing states a highly regulated environment; what certifications and / or standards does the Authority require as part of overall assurance in delivery of the service, the applications, interfaces and APIs? And to what degree are Alpha components included in this assurance? This information will be provided at the next stage of competition for the down selected suppliers. 20. What software certification engineering certification or standards does the Authority require? To what degree have the Alpha components been documented to meet this assurance level? This information will be provided at the next stage of competition for the down selected suppliers. 21. Can the Authority advise on the average and current number of defects in the Alpha and any associated trends? This information will be provided at contract award. 22. Grateful if the Authority could please advise on the current level or support required to MOD users? Will this be articulated and contracted via SLA / KPIs or a less formal basis (given the nature of the BETA)? This contract will only require support for a test user pool therefore any support required will be minimal. 23. Will MODCloud form part / all of the Beta Hosting? This information will be provided at the next stage of competition for the downselected suppliers. 24. What are the Authorities processes for CI/CD release? The supplier is required to implement and manage the 'Essential' SAFe configuration construct. 25. “the Supplier is to provide a List X premises for their team” and “the supplier will be required to facilitate collaborative, face to face planning events at their premises” – is the expectation that the majority of the Supplier’s team will be based at their own facilities, and does the Authority require the supplier to provide their own end user compute, development environments and CI / CD toolchain for integration to the Alpha / Beta systems or is this provided? Yes- The supplier is expected to work at their own premises. The supplier will expected to provide their own development devices. The supplier will initially be expected to provide the development environments up to the point where the enterprise services is made available, at which point all development environments will be provided. Most CI/CD tooling will be provided, configured and managed by the supplier, but some provided as GFX. 26. Can the Authority advise how much travel is anticipated? Can bidders charge travel as requested away from our home sites? There will be a T&S provision within the Contract for actual travel costs to be paid for. 27. Given the nature of SecDevOps and maturity of the Alpha should bidders assume this will be let under DOS 5 Lot 2 time and materials, with a Limit of Liability that would be managed by Authority and Supplier through the Planning Increment process. We are currently unsighted as to how Firm Price can be managed given the maturity of the requirement and unknown state of the backlog. The costing mechanism will be Firm price. The budget range has been provided, and suppliers will need to propose a solution that fits within that budget. Once on contract, the Authority will agree work with the supplier for each increment that falls within the available resource.