Click here to subscribe to the Helix Nebula & PICSE Newsletter

Case study - Purchasing IaaS through a public tender


The Procurer

We provide machine translation services in over twenty languages to our staff of over 2,500 and a much wider of public sector users. Our department is part of a translation service provider. organisation’s procurement process follows the general
principles of the European Union’s (EU) procurement rules: and equal treatment, consistency, integrity accountability.
The types of procurement procedures used are:
» Open call for tenders where an evaluation committee is appointed which examines all the offers;
» Call for expressions of interest.

Why the cloud?

The machine translation service uses an extensive catalogue of human translations. In providing the service we faced the following challenges:
5.Training the machines requires a lot of data;
6.Statistical computation is very expensive in terms of resources.
During the machine training phase, translation and language models are built which will then be used to translate new text. Considering that models are built to support more than 70 direct language pairs and it takes around 2 weeks to train each
engine, the reduction of the computational time is fundamental and should be done on a scalable infrastructure. Usually, the machine learning procedure takes place four times a year, and takes 2 months. Having access to a flexible and scalable cloud infrastructure with powerful computational resources would reduce time taken and provide flexibility. 
We also need large amounts of disc space and RAM to store and process the large volume of temporary data managed by the system. The data generated and managed during the intermediate stages are much larger than the input data, at around 300GB (made up of millions of sentence pairs). There are also many cores to parallelize. When the machine translation project began, cloud computing was considered as a possible solution to overcome the storage, the computational, the flexibility and scalability issues. In addition, at the time, the internal capacity to cover this was not available to us. We were also attracted by the more convenient prices offered by the cloud providers. Therefore, we decided to go for a tender procedure.


How we procured cloud services

Our organization prepared two tenders to procure cloud services. The first was launched in 2010, while a follow up was prepared but never publically launched in 2011. The very beginning of the pilot in 2010, we decided to launch a restricted call for tenders to procure IaaS. The decision was taken as we only had one month to launch the tender so as to benefit from available budget resources, which were below the required threshold for restricted calls (€60.000) that is set by our organisation. This allowed us to start small with a pilot and avoid a long and complex open tender procedure. 
An internal team was put together and in 2-3 weeks released the tender. No cost evaluation was carried out due to time constraints and a market analysis was completed by the team based on internet research only. Originally, we thought that the tender technical specifications were relatively easy to define as we knew exactly how many resources were required. However, issues arose when we approached our legal department to approve the tender. Cloud computing was a completely new subject for our legal advisors and they were unsure how to purchase the new technology. Their doubts were mainly related to the security issues such as the confidentiality of data, the location of the data, etc. However, after much discussion we finally got their approval. We then faced challenges related to the procurement process. 
Our organisation has very strict tendering procedures that don’t match well with the common purchasing practices related to IaaS, where services are offered through a web interface and are regulated by a payment through a credit card. Our procurement department requires for instance paper invoices, etc. Moreover, our organization does not usually adapt its own terms to the terms of service providers, but rather requests providers to abide to its terms. To overcome some of the procurement issues, the negotiation process started with the tender being sent to 5 suppliers who had been identified through the internal market analysis. The tender was open for three months. However, no reply was received. A year later in 2011, we prepared a new tender on the same topic. However, this was not published because our organisation started preparing a new larger tender to procure cloud solutions. We are now waiting for the new tender process to be opened
by our organization. 

What we learned


What worked well:

» Technical specifications were relatively easy to develop

What didn’t work well:

» No answers to the tender were received
» The legal team had no experience with cloud technologies.They were unsure about data security. This caused a delay of 2 weeks before the launch of the tender.
» Our organization has strict procurement policies which did not facilitate the process. For example, tenderers are required to accept the terms without any flexibility; purchasing through web interfaces and paying by credit card is unforeseen.
» We left open most of the typical SLA conditions to be set by the providers, as there was no experience on the technical side about how to deal with Cloud computing provision.


Wish list

» Guidelines on how to write technical specs, formulating needs in a way compatible to cloud computing service offer and including legal aspects.
» Our organisation’s current procurement procedures on cloud computing market and identification of points requires updating.