⇓ More from ICTworks

Six Lessons Learned in Moving FAO to Software as a Service Solutions

By Guest Writer on January 15, 2018

software as a serivce

The IT Division of the Food and Agriculture Organization of the United Nations (FAO) has overall responsibility for meeting the IT needs of over 12,000 employees working in more than 100 countries worldwide.

With such a massive responsibility, we were naturally cautious about moving core technology systems from self-hosted, customized software, to vendor-supported, cloud-computing, Software as a Service (SaaS) solutions.

At the beginning we were concerned about many aspects of the process, because adopting cloud-based solutions may be clear and easy in theory, but, as the saying goes, the devil is in the detail.

Overall, and  in spite of initial doubts, we were all pleasantly surprised with our experience in replacing the internal online commenting system for Codex Alimentarius with a new commercial, multi-language cloud-based application.

Here are our six lessons learned in the process:

1. Would SaaS Meet Our Requirements?

We were worried about SaaS meeting our requirements:

  • Inviting 187 Member Countries and 219 Observers to participate any time, from any location and any browser-equipped device they wish, in the review of Codex Alimentarius standards under discussion, and express their official position, in a user-friendly way.
  • Making Countries able to have their internal sub-review and publish comments only when they are comfortable with doing so.
  • Program managers being ready to automatically compile comments into a consolidated report soon after closing the review.
  • FAO is a UN agency to which international law applies, whereas the service provider must comply with their national laws.

After researching commercially available specialized software designed to be readily available with little or no modification, easy to use and having tested the above needs, we identified SaaS software that meets 90% of our essential requirements out-of-the-box.

That was really promising, but the next question was: what about the reaming 10% of still essential requirements?

Indeed, we invested a couple of months in discussing and negotiating the customization of what was not available out-of-the-box. The development costs were also significantly higher than our usual internal development costs.

However, thanks to the motivation of all the involved parties, first of all the provider company to accommodate user needs vis-à-vis feasibility considering the significant investment in place, and thanks to the negotiation skills of our procurement office, we arrived at the roll-out of the system with full essential functionality in place.

In the end, there was no need to be worried.

2. Could Outsourced Software Meet Our Timelines?

We were worried it would take too long to identify, evaluate and procure a suitable service/product. And indeed, it took longer than we anticipated, and it was more complex than we expected.

We knew that it would take some time for IT Division to evaluate the product and to agree on technical details such as hosting, service availability, backup, encryption,  or user management. We also knew that it would take some time for Codex Alimentarius and the provider to agree on the software customization to meet all their requirements.

However, there were other processes that required additional work:

  • Configuration of the final system and branding of the Home Page; translation to six official languages of FAO; pilot test and training for the member Contact Points.
  • Our Legal Office had to review where data would be stored and under which law the provider operates, as well as whether these countries have recognized the Convention on the Privileges and Immunities of the Specialized Agencies.
  • Procurement Office played an important role in negotiations of the contract, again in order to take into account special role of an UN agency, but also related to, among other issues, the license model and pricing.

However, despite it taking almost one year to go through an articulated risk assessment and procurement process, the time saved for implementation has been considerable compared to that which would have been required for a new in-house-built Online Commenting System.  Overall, we learned that in such a big international organization such as FAO, it is necessary to start the process early enough, and even then, delays can be expected.

3. Will SaaS be Sustainable?

We were worried about the maintenance – will the system stay up to date? How will new features be added when we need them?

In two years, we have already benefited from an upgrade to an enhanced system that meets additional requirements out-of-the box, resulting from other customer organizations of the provider company; this upgrade cost us only half an hour of downtime and a couple of hours for testing.

Now we know that sustainability is excellent, with no headaches to worry about keeping the application up-to-date and upgraded.

4. What is Software as a Service Scalability?

We wondered if it would scale to all our users. With 187 Member Countries and their multiple institutions, the number of Codex Alimentarius users would grow fast. At the time of this procurement, users’ numbers and names were not known. And over time, for different document reviews, the users would be different.

Yet, we didn’t need to worry. Should we need to add more users, we can simply adjust the license subscription as required.

5. Can SaaS Ensure Data Security?

We wondered how secure the site would be. Will we be able to preserve our data confidentiality and retrieve it definitively at contract end?

We have experienced no major data security issues to date. The system is on a dedicated server, stable and registers good performance. “Our system is not lost somewhere in the Clouds – but is accessible in the cloud.”

6. Will SaaS Providers Have Good Support?

We worried that we would not get a timely response. However, service provider’s IT support is friendly, accurate, timely and responsive when we experience unexpected user problems that we did not foresee in our risk assessment process.

For example, the system is configured to send automatic invitations to participate in reviews, or reminders of approaching deadlines.  A few weeks after deployment we started receiving hundreds and hundreds of “undelivered email” notifications which was mostly due to the recipients’ security systems rejecting the automatic emails considering them “suspicious”, because the sender address belonged to FAO domain but emails were actually sent from the SaaS email server.

Additional work had to be done to identify the problem and implement some mitigation measures that now consist of having the automatic notification emails sent from the SaaS email address, and just indicating Codex Alimentarius in the user name part of the address. It is not the optimal solution, but it works and is acceptable. We still have cases of undelivered mail due to various other reasons, which still implies for us a user “reach-out” case by case: time-consuming work.

In the process we learned that it is simply not possible to foresee all potential problems, even with a comprehensive evaluation and risk assessment done both by FAO and the service provider.

Conclusion: Software as a Service is Viable for FAO

Overall, we learned that “built-in-house software is a “dedicated” system with one Business Owner to support the costs. Cloud-computing SaaS is a “specialized” system with costs shared among hundreds of Business Owners”.

In addition, we realized that the process of buying IT services is very different from building a solution in-house. In our case, it was necessary to combine knowledge and experience of several business areas in FAO:

  • The Codex Alimentarius (specific domain knowledge and the required functionality of the IT solution).
  • IT Division (general IT domain including information security and user management).
  • Procurement (contracts with providers).
  • Legal Office (data protection and special status of FAO as an international organization).
  • Office for Corporate Communication and Finance Division.

In the process, all those involved learned something new about the others’ domains. Now we know that next time we have to strengthen the risk assessment and analysis but we also feel better equipped to deal with similar projects in the future.

And last but not least, using Cloud and SaaS systems can be successful, with some important prerequisites by the internal IT Division, which must be able and ready:

  • To initially ADVISE during the identification of the SaaS and its acquisition
  • To SUPPORT the IT requirements and security aspects during the initial set-up, integration and usage of the system.
  • To assist in MONITORING the evolution of the on-going service and its long-term potentiality.

All this shows clearly how technological development and trends change the traditional role of both IT Division and business offices when acquiring cloud-based IT solutions. 

By Gordana Korolija and Donatella Mori, two IT specialists at FAO, working on the IT provider and IT customer “collaborative fronts”.  The views expressed in this post are those of the authors and do not necessarily reflect the views of the Food and Agriculture Organization of the United Nations (FAO).

 

Filed Under: Software
More About: , , , , , , ,

Written by
This Guest Post is an ICTworks community knowledge-sharing effort. We actively solicit original content and search for and re-publish quality ICT-related posts we find online. Please suggest a post (even your own) to add to our collective insight.
Stay Current with ICTworksGet Regular Updates via Email

Sorry, the comment form is closed at this time.