ICT13629 - iBus2 Integration Proof of Concept

Tender description

Summary of the work Carrying out a Proof of Concept to prove that a legacy solution can be decoupled using integration services in order to mitigate the risk of transition and simplify future integration. Latest start date Monday 24 August 2020 Why the Work is Being Done To support the iBus2 Procurement in late 2020, TfL wish to carry out a Proof of Concept (PoC) on the use of integration services to decouple legacy services and transition to new solutions. Please note that the entire PoC will need to be completed by 02/11/2020. Further details on the PoC, the high level requirements and the expected deliverables are contained within the 'PoC Supporting Document. Please contact Jud Broscombe-Walker (JudBroscombeWalker@tfl.gov.uk) to receive a copy of the document. Problem to Be Solved TfL currently has a legacy service to monitor and control the Bus Services, which is due for replacement. TfL wishes to test the principle of using integration services to decouple this legacy service to mitigate the risk of transition and simplify future integration. Who Are the Users As a member of the iBus2 Project Team, I need to understand the feasibility of using integration services to de-couple legacy services and transition to a new solution in order to help TfL shape its approach to integration and transition for the iBus2 Project. Existing Team The supplier will be working with TfL Technology and Data resources as well as the incumbent supplier of the current system. Current Phase Not applicable Skills & Experience • have experience of using integrataion services and software on legacy systems that were not originally architechted to be integrated • have experience in developing ETL within integration to convert proprietary protocols to recognised Industry Standards • have experience in providing integration services scaleable to facilitate 10k complex transactions between client systems per second in near real time, with negligible effect on performance of the connected systems Nice to Haves • have experience in providing integration service, software and support to the transport industry • have experience in utilising the following transport real time data standards; SIRI-vm, SIRI-sm (extended) and SIRI-sx Work Location 14 Pier Walk London SE10 0ES (Depending on Government guidelines) Working Arrangments Due to current COVID restrictions and guidelines, the majority of the effort is expected to be carried out remotely. No. of Suppliers to Evaluate 5 Proposal Criteria • Understanding of TfL and the problem being addressed by the PoC, highlighting any areas of challenge or focus that will need to be solved early on to achieve success. • Proposed methodology to ensure that the High Level Requirements will be delivered in terms of the PoC and production service which will be informed by the PoC. • A detailed project plan that sets out the activities that will be carried out and supports the timescales for the PoC that TfL requires • A detailed resource plan that sets out whether the Supplier, TfL or the TfL legacy supplier will be responsible for the delivery of the activities in the project plan Cultural Fit Criteria Provide evidence of experience using PoCs to develop Clients understanding of technology, and supporting the client to develop further requirements in an unbiased and open manner. Payment Approach Fixed price Evaluation Weighting Technical competence 52% Cultural fit 8% Price 40% Questions from Suppliers 1. What is the budget? We have an approved budget available for this Proof of Concept. However, we are unable to share the budget with suppliers due to its commercially sensitive nature. 2. What is the length of the contract? It is expected that the Proof of Concept will last for 6 months. However, we will require any associated licences for up to 12 months. 3. Do you have a preference for a particular integration platform/tooling? No, we have explored a number of solutions prior to issue of this Proof of Concept. As long as the platform is capable of real time transformations and integration, and has the needed connectors, TfL are agnostic of platform. 4. Your supporting document appears to require a full proposal which would contradict the DOS Stage 1 response requirement of 100 word answers for the five Stage 1 questions. Please clarify what you expect for the Stage 1 submission. For Stage 1 of the submission, please adhere to the 100 word limit as stipulated by the DOS response requirements. An updated v2.0 of the PoC Supporting Document will be circulated clarifying the word limits. 5. Does the Authority have any preference on the technology stack for the PoC? No, we have explored a number of solutions prior to issue of this Proof of Concept. As long as the platform is capable of real time transformations and integration, and has the needed connectors, TfL are agnostic of platform. 6. How many (roughly) data entities of On-Board-Unit service will be within the scope of the PoC? The expectation is to extract Vehicle ID, Service ID, current Locations and Schedule deviation from the vehicle message, the headway from the back office to vehicle message, and all these for transmission to an external system 7. Do you have a preference on the underlying integration platform to be used for this PoC? No, we have explored a number of solutions prior to issue of this Proof of Concept. As long as the platform is capable of real time transformations and integration, and has the needed connectors, TfL are agnostic of platform. 8. Are you able to share the budget that you have available for this work? We have an approved budget available for this Proof of Concept. However, we are unable to share the budget with suppliers due to its commercially sensitive nature. 9. Could you please expand on the timetable of activities between submission of this stage 1 response on the 17th August and starting work on the 24th August? Following the response on 17th August, we shall evaluate suppliers stage 1 response to the Skills and Experience section, and shortlist down to 5 suppliers for the next stage. Shortlisted suppliers will then have their Technical Competence (including Proposal criteria). Cultural Fit and Price responses evaluated. 10. In terms of the remote working, are we able to provide this from nearshore or offshore locations? Subject to appropriate security considerations and adherence to all applicable Data Protection laws, TfL have no issue in principle with the PoC being carried out via remote working from a near-shore location. However, subject to restrictions relating to Covid-19, TfL reserves the right for physical meetings to take place at its London offices as set out in the initial requirements. Remote working from off-shore locations would not be acceptable. 11. On the requirements for this PoC is it stated:“The supplier will be precluded from participating in any future procurement relating to the iBus2 project."Can you please confirm that the supplier of the PoC will be precluded both from supporting the procurement and tendering for the delivery work? One of the deliverables of the PoC will be a Requirements document for the production interface which will be used in iBus2. However, TfL does not envisage any active support from the Supplier during the procurement phase of iBus2. As a key deliverable will be the set of Requirements for the production interface TfL would need to preclude the supplier of the PoC from bidding for the production interface in order to maintain its obligations regarding fairness and transparency under PCR2015. 12. You have allowed 1 week from receipt of Stage One bids and the start of work. Would you consider revising this? The DOS process normally allows at least one week for the buyer to assess Stage One 100-word answer responses, then notifies unsuccessful bidders and gives shortlisted bidders at least two weeks to prepare a written proposal, case studies and CVs. It then allows at least a week for the buyer to assess bidder proposals. There should then be a 2-week Alcatel standstill.There is plenty of guidance on this and templates to be found at:https://www.gov.uk/guidance/ways-to-assess-digital-outcomes-and-specialists-suppliers The iBus2 Programme is running to aggressive timescales. TfL read all the guidance notes on the Digital Outcomes framework prior to starting the procurement and sees no need to revise the original timescales 13. For bidders that are shortlisted, when is the full proposal (covering proposal criteria, cultural fit and price) due by and in what format will this be required? TfL will require a written proposal in Microsoft Word or pdf format not exceeding 20 pages. Due to TfL not knowing the volume of potential bids for evaluation TfL cannot commit to a date for shortlisting to be complete but this requirement is being treated as a priority within the iBus2 Programme and therefore will be working to short listing being complete by the end of the week commencing 17th August, 2020. Shortlisted bidders will be afforded a week to submit their proposals 14. We wanted to understand how the 10k tps can be generated given the population of buses and their operating cycle on the road and in their garages. Please can you explain the build up of transaction volumes over time for an estimated daily cycle and the periods over which they would be expected? TfL have c. 10,000 buses in live operation and each bus will send location data every 10-30 seconds, hence the 10k tps. (Please note, for the the purpose of this PoC, we may not use all of the buses, but the solution should be able to scale up to this volume) 15. On the requirements for this PoC is it stated:“The supplier will be precluded from participating in any future procurement relating to the iBus2 project."This is still unclear. From our perspective, as a services and software vendor, the successful PoC will be delivered using our own software, if we are successful in delivering the PoC how can we then be precluded from delivering the Production System which is based on our software ? As the PoC supplier will be assisting in creating the requirements for the production service, this would present them an unfair advantage in the OJEU procurement. 16. Will the production platform have the same requirements of the POC – eg. Must it be SaaS, provided as a hosted service or other? The whole point of the PoC is to test assumptions TfL have regarding the interface and identify the best approach, therefore at this stage TfL is unable to definitively answer whether the production interface will be exactly the same as the PoC. 17. What is the data format(s) being used by the OBU? If not a standard industry specification or format is the format documented and by whom?What are the expected integration points with new iBus 2 Back Office systems, in terms of protocols, formats, interfaces and patterns?Are there any particular commercial systems, products or technologies expected to form part of iBus 2 (in real production deployment) which will require a degree of integration? The current protocol is called NLSm and it is the incumbent suppliers over the air protocol, based on sending ASCII messages using UDP.The new iBus2 Back Office should use ITxPT or other open standard protocols. The format should be SIRI/XML/JSON.The new Back Office will integrate to other corporate TfL applications (for example traffic light management system, Countdown displays). 18. You say that the OBU communicates with iBus 1 via IP over GPRS. For the POC, can you confirm that TfL be providing an OBU emulator which will be accessible locally and/or remotely over standard internet protocols? Yes, the OBU will be supplied by TfL (and the incumbent Supplier) 19. For the PoC, what will be the simulated Back Office system(s), especially in terms of protocols, formats, interfaces and patterns?For the PoC, who will be providing the simulated Back Office system(s)?You say that DMR is also used to communicate with unspecified third-party systems. Are we correct to assume that this is piece is out of scope for the POC? The simulated Back Office will be supplied by the incumbent supplier or TfL. The protocol and interfaces need to be developed by the proof of concept supplier. 20. Can you confirm the logistics in terms of ways of working, particular during POC execution. Is remote working expected and feasible, given potential Covid-19 restrictions?Is the provider of the current OBU participating or otherwise supporting the PoC? As a result of Covid-19 TfL would expect the work to be carried out remotely. However, as per previous responses to bidder questions, any work should be carried out either within the UK or near-shore. Off-shore working is not permitted. TfL does reserve the right if needs be for face-to-face meetings to be held at it's London offices, however, in the current environment this would very much be a matter of last resort 21. Is the provider of the current OBU participating or otherwise supporting the PoC?Is the Vehicle Connector service in scope for replacement in the POC or must the POC interface to it?When we accessed the Opportunity on the 4th August there was already one complete application, is this correct, bearing mind it was only released on the 3rd August. Could you please confirm when we receive the answers to questions from the date of question submission. The current OBU provider is assisting in the PoC only to the extent that it will be supporting and providing information to the successful supplier in how to interface with their solution and providing all necessary documentation. They are not bidding for the PoC under the DOS framework.Considering the aggressive timescales for the PoC TfL is endeavouring to respond to bidder queries in as timely a manner as possible. TfL cannot guarantee a same day turnaround to queries. 22. Further to your answer number 11, we seek further clarification on the preclusion of the POC supplier from building the production solution. The requirements document deliverable will be made public to all bidders, therefore under PCR we expect that the POC provider would have no incumbent advantage and should be permitted from tendering for the production iBus2 interface. Can you reconsider your clarification in this respect? As the PoC supplier will be assisting in creating the requirements for the production service, this would present them an unfair advantage in the OJEU procurement. 23. Referencing figure 1 of the scope on page 3, please can you confirm whether the scope of delivery includes just the "PoC Integration Platform" or also the interfaced system to "Simulate iBus2 Back Office"? The scope of delivery includes both PoC Integration Platform and the interfaced system to simulate iBus2 Back Office. 24. In reference to clarification 3, you have "explored a number of solutions prior to issue of this Proof of Concept". Please can you list which specific technical solutions/integration platforms you have considered We are currently still assessing internal development using Azure stack. 25. Regarding clarification 9 on the procurement process, we understand you will downselect to 5 based on the DOS stage 1 answers submitted on the digital marketplace portal. Can you confirm the date when the downselection is expected to be announced, and the subsequent second stage response window and deadline date for the submission of the response for the second stage? Deadline for Stage 1 - shortlisting is 11:59pm on Monday 17th August, 2020. Due to TfL not knowing the volume of potential bids for evaluation TfL cannot commit to a date for shortlising to be complete but this requirement is being treated as a priority within the iBus2 Programme and therefore will be working to shortlising being complete by the end of the week commencing 17th August, 2020. Shortlisted bidders will be afforded a week to submit their proposals 26. You have requested a fixed price proposal, but it would appear there are significant dependencies and uncertainties for the delivery. How should we account for these within the commercial proposal? Whilst TfL accepts that there dependencies and uncertainties in the delivery of the PoC, this is no different to any other project. The timescales for the delivery of the PoC are relatively short so any successful supplier is unlikely to carry risk for an extended period of time. Each Supplier will account for risk around dependencies and uncertainties their own way in accordance with their own internal commercial processes. 27. Please can you provide more details on the calculation required for the emulation? Please can you provide more information on what calculations you refer to in your question? 28. Over what timescale is the POC expected to be working? It is expected that the Proof of Concept will last for 6 months. However, we will require any associated licences for up to 12 months. 29. What operating system is the iBus1 application running on? The iBus1 application is running on Windows and Oracle. 30. How helpful will the incumbent vendor be? For example, can we get a duplicate feed of data between the OBU and the core systems. It will not be possible to get a live feed from the OBU System, however, we can expose DB data 31. Is the volume because of 1 second reports of position? Are we allowed to perform geo-spatial compression? TfL have c. 10,000 buses in live operation and each bus will send location data every 10-30 seconds. Geo-spacial compression is not required 32. Please confirm the availability of test OBU and display boards and an SME Support person. Yes, TfL will provide. 33. Is the current functionality of core systems and protocols for push to mobile and roadside devices is out of scope for the POC? Yes, these functionalities are out of scope. 34. How do we submit the 2 page documentation required? For Stage 1 of the submission, please adhere to the 100 word limit as stipulated by the DOS response requirements. 35. Is it expected that the PoC will be required to calculate the actual Headway data? Yes 36. Please can you provide more details on the calculation required for the emulation? Does your question refer to the calculation for headway? 37. What other use cases are required for the PoC apart from the Headway use case? The ability to break/intercept messages from legacy OBU and consume in integration layer is the key ask. 38. Current connectivity mechanism: do the displays and devices need to be called with a web service from our platform? or do they use web-sockets or other pub-sub? Current, the system doesn't communicate over Web Services or pub-sub based model. They do use their own component to maintain state. 39. The requirements seem to relate only to real-time interfaces, but the evaluation criteria includes development of ETL Development part of ETL is to process the location data into different format. i.e. legacy to open standards 40. For building the proof of concept will an OBU be provided to us, or will this be mocked. If mocked will we have to build the mock? If not mocked, will the unit be configured to function as a viable test bed? Yes, the OBU will be supplied by TfL (and the incumbent Supplier) 41. For GPRS comms, as this is a PoC can this be mocked as an IP end-point, or must a GPRS Gateway be included in the PoC Spec? The existing OBU connects via a web socket and GPRS, this will need to be consumed within the Interface layer. TfL have full access to our GPRS gateways for the solution and can work with supplier to reconfigure these gateways if this is preferable. 42. Does TfL have any technology stack expectations i.e. use of existing licensed technology? No, we have explored a number of solutions prior to issue of this Proof of Concept. As long as the platform is capable of real time transformations and integration, and has the needed connectors, TfL are agnostic of platform. 43. Does TfL have a preferred cloud platform? We deliver project with both Azure or AWS, given free choice we would likely recommend Azure for this project, but comfortable with either. TfL does not have a preference over cloud environment selection. 44. Are messages from the OBU in CEN SIRI format, or is this the format that we must map to? The existing OBU uses a proprietary data format, which will need to be converted into SIRI-vm 45. What is the reasoning for excluding the winning supplier from future procurement related to the iBus2 project? As the PoC supplier will be assisting in creating the requirements for the production service, this would present them an unfair advantage in the OJEU procurement. 46. Will shortlisted unsuccessful bidders also be excluded? No 47. Will longlisted unsuccessful bidders also be excluded? No 48. You have listed a start date of 24th August and a completion date of 2nd November, and you have a fixed cost approach. Given the requirements are only outlined at a high level, what is your expectation regarding the management of scope, time and cost variables? Scope will be confirmed on contract award, as will time and cost, any variations will need to be flowed through TfL change control and approved by both TfL and supplier. There is a small amount of room within timescales, however the driver for date will be the intended launch date of the iBus2 procurement. 49. As a DOS4 supplier, we have signed up to work under the GDS Technology Code of Practice https://www.gov.uk/government/publications/technology-code-of-practice/technology-code-of-practice are your expectations that we work to this framework? Whilst TfL does not adhere vigorously to the GDS Code of Practice, it fully supports many of the underlying principles such as an open standards approach and breaking down requirements into smaller more manageable and component based procurements 50. We also have signed up to work to the GDS Service manual which mandates Agile delivery https://www.gov.uk/service-manual/agile-delivery. Is your expectation that we would work to this method? And if so would you agree that this project would contain elements of Alpha phase and Discovery phase? We can conform with a strict agile framework such as this, our own proven agile approach, or a more structured approach such as we find many clients preferring. We are open to differing delivery methodology, your responses should make clear the methodology proposed, and any stages within it. This can be strict agile or waterfall or a hybrid approach, please ensure the approach is clear as to ensure no misunderstanding on either part. 51. Part of the eval criteria includes identifying which activities will be delivered by TfL resource – can we get a better understanding of what TfL resource will be allocated to this project? TfL has a number of resources available, either already assigned to the project or that can be assinged at need. These could include Solution architects, Business Analysts, Developers, Network and or Infrastructure architects. This requirement is for the suppliers to state their expectations of TfL input and support. The intent is to ensure a balance that reflects the efforts and bid costs. 52. Are there any particular data transfer, location or security standards the Supplier would need to adhere to? Subject to appropriate security considerations and adherence to all applicable Data Protection laws, TfL have no issue in principle with the PoC being carried out via remote working from a near-shore location. However, subject to restrictions relating to Covid-19, TfL reserves the right for physical meetings to take place at its London offices as set out in the initial requirements. Remote working from off-shore locations would not be acceptable.