Expressing requirements

Functional requirements

As was described in the second part of this book, the Google Apps offering is structured around two themes:

  • Communication tools: Gmail, Google Calendar, Google Talk
  • Collaborative office tools: Google Documents, Google Sites, and Google Video

It is thus necessary to precisely qualify the requirements regarding these two topics, to identify which applications will actually be made available to users. Depending on the needs or constraints of a company, it is sometimes better not to enable some of them: Google Talk, Google Video, or even Google Documents, and so on.

Usually, choosing among communication and office tools in Google Apps is rather obvious. The choice might be more delicate for other Google services, though. Among these, the following might prove particularly useful:

  • Global indexation of data in the IS using Google's dedicated search tool: Enterprise Search Appliance
  • Reporting through Google Spreadsheet and the Secure Data Connector
  • Managing enterprise workflow through third-party extensions from the Google Apps Marketplace, and so on

To this, one should add the data-transfer tasks, which means importing existing data into Google Apps. For each Google application, this will determine the workload during the preliminary analysis phase as well as during the actual migration phase.

A lack of data transfer requirements might make the pilot phases superfluous. On the other hand, importing data (because the mail system is obsolete, has an exotic configuration…) could imply specific, ad hoc developments. Although a number of tools are provided by Google, they won't necessarily suffice in all situations.

Non-functional requirements

Advanced integration of the Google Apps in the IS often implies planning a larger migration project. One or more additional steps can be required. As examples, let's mention the following projects:

  • Setting up a Single Sign-On mechanism that will provide automatic authentication on any desktop (on SSO issues, we refer you to Chapter 8, Federated Identity and SSO).
  • Developing specific applications (for example advanced contact management). These applications can both interact with the IS through Google APIs or be deployed directly on the Google Apps Engine infrastructure.
  • Multichannel access pilot: Although multichannel access is native in the Google Apps platform, it might still need an experimental phase, for mobile terminals.
  • Integration with an intranet portal that incorporates Google Apps' data through dedicated widgets.

Security and availability of tools are among the most often quoted assets which motivate the SaaS model. However, during a migration project, these two perceived advantages might sometimes be put to the test. One priority of the pilot project is to mitigate and, when possible, eradicate any concerns related to these topics.

Finally, depending on the desired integration level, it could be necessary to anticipate a rollback plan, which warrants a phase of its own in the migration project.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset