CGIAR ICT Roadmap

CGIAR Information and Communications Technology Roadmap and Action Items: A Three Year Perspective

Prepared by the Office of the

CGIAR Chief Information Officer

December 2010

CGIAR ICT Roadmap Page 2

Executive Summary

This document includes a three-year roadmap in the area of Information and Communications Technology. It proposes twenty-four prioritized Action Items for the CGIAR, divided into five general areas.

These Action Items were developed, discussed, and prioritized by the ICT managers of the CGIAR Centers. Each of the Action Items is a standalone project with specific deliverables. In addition to the Action Items themselves, this plan contains background information, rationale for each area, environmental scans of the CGIAR and related organizations, as well as a business case or business need for each Action Item.

The starting point for the roadmap was the Strategy and Results Framework documents [SRF] on the Design and Establishment of the Consortium of CGIAR Centers. Within these documents, the concept of “shared services” across CGIAR centers is called out in “Key Findings and Recommendations from the Consultancy on Common Administrative, Financial, and Research support Services in the new Consortium of the CGIAR Centres (November/2009),” hereafter, the “Accenture Report.” These shared services across the CGIAR centers were focused largely on information technologies. In the Accenture Report, it was noted that

“… shared services in IT can drive improved specialization and increased services. Efficiency gains can potentially free up IT personnel to focus on strategic uses of technology to help drive the future research agenda instead of tactical IT support within a specific Centre. “

The Accenture Report identified five key goals that shared services within the CGIAR would support:

· “Improve the effectiveness and quality of research by allowing Centres to focus more time and resources on core research activities · Increase collaboration and knowledge sharing within and across Centres through the introduction of standards and collaboration tools · Increase productivity and efficiencies of research support, administrative and financial services through use of industry leading practices and tools · Improve the ability of the CG system to quickly scale and respond to potential increases in funding and introduction of CGIAR Research Programs (CRPs) · Reduce redundancies in spending, technologies and resources by sharing common back- office and research support services” (Accenture Report, page 13)

Based on these five goals, 15 very broad shared services initiatives (page 20), ranging from “standardize ways of working” to “share donor intelligence,” were


proposed. While the very broad initiatives provide high-level guidance, the Accenture Report didn’t offer a detailed implementation plan. Thus, the CGIAR turned to its own ICT managers to flesh out the broad initiatives. The ICT managers developed a series of “action items” to build a 3-year roadmap for shared services ICT deployment within the CGIAR. Those action items form the core of this document.

Over a three-month period (July to September, 2010), as a group effort, the CGIAR ICT managers met electronically and via conference call in small groups to develop a set of action items. The discussions were divided into five general topic areas, and each topic area was covered by a team of ICT managers, with most managers participating in more than one team.

In October, 2010, the ICT managers met in Addis-Ababa for a face-to-face meeting. During the week-long meeting, the five topic areas were combined into this document. Each action item was discussed, both in small group discussions and, finally, in a full meeting of all managers. When the action items had been agreed upon, ICT managers worked together to prioritize and order the final set of twenty-four. Finally, budget estimates were prepared for the highest priority items.

This document doesn’t represent a final three-year plan with a timeline, but a rolling analysis of the action items needed for shared services within the CGIAR. Each year, it is expected that this roadmap will be re-visited to verify its applicability, to re-confirm priorities and initiate new projects from the action item lists, and to further fine-tune the roadmap. To begin, the following immediate recommendations for implementation of the highest priority seven action items beginning in CY2011 are offered.


Title Description and Proposed Project Scope

Internet Connectivity

Description: Establish minimum standards for Internet connectivity, including guidelines for selecting vendors, media (wires/wireless/VSAT), and types of circuits.

Scope: Prepare policies and negotiate contracts based Internet requirements across different regions in the CGIAR; manage Internet contracts and handle purchasing, negotiation, and project administration.

Resource Requirements

3 person-months for research, policy establishment, contract negotiation at project initiation; 2 full-time staff continuing to handle admin/finance tasks and manage program.

Common Data Repository for

CRPs and beyond

Description: In conjunction with appropriate partners within CGIAR, a Common Data Repository for CRPs should be developed, including data dictionary and with full access control/security capabilities. Both known data objects and potential future data objects should be supported. This action item has scope beyond CGIAR Research Programs (“mega-programs”) as well, and may have results with broad applicability.

Scope: Establish requirements definition and project design; prepare white paper comparing hosted versus cloud; research on existing repositories for “meta” repository; detailed design of repository; develop access control guidelines, archiving, publishing, and data dictionaries; create repository and operate repository for all CGIAR


60 person months to design, contract, and deploy system. Hardware costs of approximately $250,000. Continuing staffing of 1 person full-time to manage/maintain (or outsourced contract).

One Corporate System

Description: Support the selection and deployment of back-office software as part of the One Corporate System initiative. Investigate any bandwidth/connectivity requirements and integration with document management systems/corporate repositories that OCS will require when it is rolled out.

Scope: Monitor OCS project and provide ICT input; report and gather feedback; full-time participation and liaison regarding ICT function; progress reporting and documentation

Resource Requirements 1 full-time person for life of OCS project.

Backup, Data Protection,

Business Continuity

Description: Establish CGIAR data backup systems focusing on the needs of under-served and small offices, including day-to-day automated solutions as well as cloud-based backup services.

Scope: Establish backup system policy; establish cloud policy and contract; establish best practices guidelines for business continuity; contracting for service; establish and initiate service.


4 person-months at project initiation; continuing ¼ full-time person for management of service and assistance to participating Centers


Title Description and Proposed Project Scope

Active Directory

Description: Continuing program of maintenance, education, and development of CGIAR Active Directory.

Scope: Creation of knowledge base, community of practice, training materials. Update status of directory. Extend AD beyond simple Exchange/Windows uses. Write governance policy. Deliver training program in 3 regions; continuing daily monitoring and maintenance of AD


4 person-months at project initiation; 3 weeks training annually; continuing ¼ full-time person (or outsourced) for monitoring and maintenance and management.

Develop a Collaboration and

Social Media Toolbox

Description: Make available to all CGIAR staff, support, and promote a collection of collaboration tools (locally hosted or cloud-based, as appropriate), including collaboration platforms, desktop sharing, video and audio conferencing.

Scope: Identification of tools based on action item; product selection; development of training materials and decision matrix; best practices establishment; governance development; continuing outreach and training program; operation of collaboration platform CGIAR-wide including licensing and conferencing services.


3 person-months at project initiation; continuing ½ full-time person and ¼ full-time person; hardware/bandwidth costs; annual licensing costs.

Enterprise Single Sign-on

Infrastructure

Description: Design and deploy an enterprise single sign-on infrastructure.

Scope: Requirements definition and project design only

Resource Requirements 2 person-months


Table of Contents

Executive Summary ......................................................................................... 2

Introduction .................................................................................................... 8

Priority Initiatives ............................................................................................ 9

TOPIC AREA: Application Layer ....................................................................... 11

OVERVIEW ................................................................................................................................................ 11 BACKGROUND AND RATIONALE .................................................................................................... 11 ENVIRONMENTAL SCAN .................................................................................................................... 12

OCS - One Corporate System ................................................................................................................. 12 Other System-Wide Applications........................................................................................................ 12 Enterprise Architectures ........................................................................................................................ 12 Survey of Application Usage ................................................................................................................. 13

ACTION ITEMS ........................................................................................................................................ 13 A1) One Corporate System .................................................................................................................... 13 A2) Enterprise Application Framework ......................................................................................... 14 A3) Common Data Repository for CGIAR Research Programs and beyond ................... 14 A4) Lifecycle of Shared and Standardized Applications ......................................................... 15 A5) Data Management and Collection Tools for Research .................................................... 15

TOPIC AREA: Communication & Collaboration Tools and Techniques .............. 16 OVERVIEW ................................................................................................................................................ 16 BACKGROUND, ENVIRONMENTAL SCAN, AND RATIONALE .............................................. 16 ACTION ITEMS ........................................................................................................................................ 17

C1) Develop a VoIP strategy for the CGIAR system .................................................................... 17 C2) Develop a collaboration and social media toolbox. .......................................................... 18

TOPIC AREA: ICT and Organizational ICT Governance ...................................... 20 OVERVIEW ................................................................................................................................................ 20 BACKGROUND, ENVIRONMENTAL SCAN, AND RATIONALE .............................................. 20 ACTION ITEMS ........................................................................................................................................ 21

G1) Identify Critical Center ICT services supporting Science ................................................ 21 G2) Rightsource ICT services at Centers with a global view ................................................. 21 G3) Transform ICT from Service Provider to Strategic Partner .......................................... 22 G4) Improve ICT maturity at Centers .............................................................................................. 22 G8) Establish Appropriate CGIAR-wide ICT Standards ........................................................... 23

TOPIC AREA: Location Strategies .................................................................... 24 OVERVIEW ................................................................................................................................................ 24 BACKGROUND AND RATIONALE .................................................................................................... 24 ENVIRONMENTAL SCAN .................................................................................................................... 24 ACTION ITEMS ........................................................................................................................................ 25

L1) Provide ICT Support, Training, and Procurement to Under-Served Offices .......... 25 L2) Backup, Data Protection, Business Continuity .................................................................... 26


L3) Global Standards for Network Infrastructure ..................................................................... 27 L4) Internet Connectivity....................................................................................................................... 27 L5) Optimizing Wide Area Network Connections ...................................................................... 28

TOPIC AREA: Network and Telecommunications Infrastructure Services ......... 29 OVERVIEW ................................................................................................................................................ 29 BACKGROUND AND RATIONALE .................................................................................................... 29 ENVIRONMENTAL SCAN .................................................................................................................... 30 ACTION ITEMS ........................................................................................................................................ 30

N1) Active Directory ................................................................................................................................ 30 N2) Enterprise Single Sign-On infrastructure ............................................................................. 31 N3) Cloud Computing - Utility Computing, Outsourced Services, and SaaS .................. 32 N4) CGIAR-wide VPN redesign, firewall upgrade, and filtering options ......................... 33 N5) CGIAR Security Operations Center ........................................................................................... 33 N6) CGIAR-wide Equipment and Training contracts ............................................................... 34 N7) Strategy for IPv6 ............................................................................................................................... 35

Participating ICT Managers ............................................................................ 36

References ..................................................................................................... 37

Appendices .................................................................................................... 39 Maturity Model: A Definition ............................................................................................................ 39 COBIT: A Definition ............................................................................................................................... 39 Enterprise Architecture: A Definition ........................................................................................... 40 Unified Communications: A Definition ......................................................................................... 42

What is Unified Communications? .................................................................................................... 42 Two Types of UC Applications ............................................................................................................. 42 UC Applications .......................................................................................................................................... 43 UC Applications .......................................................................................................................................... 44

Cloud Computing: A definition ......................................................................................................... 45 What is Cloud Computing? .................................................................................................................... 45 Types of Cloud Computing ..................................................................................................................... 45

Single Sign-on: A Definition ............................................................................................................... 47 Introduction ................................................................................................................................................. 47 Benefits of Single Sign-On ...................................................................................................................... 47


Introduction

This document presents a three-year roadmap for Information and Communications Technology (ICT) for the new CGIAR System. The plan is presented as a series of Action Items in five key areas of ICT:

- Applications and Upper Layer Services - Collaboration Tools and Techniques - ICT Governance - Geographic Location and Mobility Issues - Network Infrastructure and Security Services

These Action Items were developed, discussed, and prioritized by the ICT managers of the CGIAR Centers. Each of the Action Items is a standalone project with specific deliverables. In addition to the Action Items themselves, this plan contains background information, rationale for each area, environmental scans of the CGIAR and related organizations, as well as a business case or business need for each Action Item.

The starting point for the roadmap was the Strategy and Results Framework documents [SRF] on the Design and Establishment of the Consortium of CGIAR Centers. Within these documents, the concept of “shared services” across CGIAR centers is called out in “Key Findings and Recommendations from the Consultancy on Common Administrative, Financial, and Research support Services in the new Consortium of the CGIAR Centres (November/2009),” hereafter, the “Accenture Report.” These shared services across the CGIAR centers were focused largely on information technologies. In the Accenture Report, it was noted that

“… shared services in IT can drive improved specialization and increased services. Efficiency gains can potentially free up IT personnel to focus on strategic uses of technology to help drive the future research agenda instead of tactical IT support within a specific Centre... common processes and systems can reduce time in finance spent working on manual processes, reconciliation and reporting… standards for collecting, managing and disseminating information can increase collaboration within and across Centres, and also reduce the risk of losing data and institutional knowledge “

The Accenture Report identified five key goals that shared services within the CGIAR would support:

· “Improve the effectiveness and quality of research by allowing Centres to focus more time and resources on core research activities · Increase collaboration and knowledge sharing within and across Centres through the introduction of standards and collaboration tools · Increase productivity and efficiencies of research support, administrative and financial services through use of industry leading practices and tools · Improve the ability of the CG system to quickly scale and respond to


potential increases in funding and introduction of CGIAR Research programs (CRPs) · Reduce redundancies in spending, technologies and resources by sharing common back- office and research support services” (Accenture Report, page 13)

Based on these five goals, 15 very broad shared services initiatives (page 20), ranging from “standardize ways of working” to “share donor intelligence,” were proposed. While the very broad initiatives provide high-level guidance, the Accenture Report didn’t offer a detailed implementation plan. Thus, the CGIAR turned to its own ICT managers to flesh out the broad initiatives. The ICT managers developed a series of “action items” to build a 3-year roadmap for shared services ICT deployment within the CGIAR. Those action items form the core of this document.

Over a three-month period (July to September, 2010), as a group effort, the CGIAR ICT managers met electronically and via conference call in small groups to develop a set of action items. The discussions were divided into five general topic areas, and each topic area was covered by a team of ICT managers, with most managers participating in more than one team.

In October, 2010, the ICT managers met in Addis-Ababa for a face-to-face meeting. During the week-long meeting, the five topic areas were combined into this document. Each action item was discussed, both in small group discussions and, finally, in a full meeting of all managers. When the action items had been agreed upon, ICT managers worked together to prioritize and order the final set of twenty-four. Finally, budget estimates were prepared for the highest priority items.

This document doesn’t represent a final three-year plan with a timeline, but a rolling analysis of the action items needed for shared services within the CGIAR. Each year, it is expected that this roadmap will be re-visited to verify its applicability, to re-confirm priorities and initiate new projects from the action item lists, and to further fine-tune the roadmap. To begin, the following immediate recommendations for implementation of the highest priority seven action items beginning in CY2011 are offered.

The remainder of this document outlines the most critical Action Items identified by the ICT managers, and provides additional detail for readers interested in the rationale and business case behind each action item.

Priority Initiatives

The ICT managers of the CGIAR prioritized the action items in this roadmap by dividing them into three priority classes: highest, normal, and lowest. Based on the collective ranking of the ICT managers, the action items are ordered below from highest priority to lowest priority. Please note, however, that the rankings are rough and that within each of the four groupings identified (by color or P1/P2/P3/P4 level) below, the items are approximately equally ranked. In other


words, all action items ranked “P3” have approximately the same priority with the ICT managers of the CGIAR Centers.

L4 P1 Internet Connectivity

A3 P1 Common Data Repository for CRPs

A1 P1 One Corporate System

L2 P1 Backup, Data Protection, Business Continuity

N1 P2 Active Directory

C2 P2 Develop a "collaboration toolbox"

N2 P2 Enterprise Single Sign-on Infrastructure

G3 P2 Facilitate organization-wide ICT transformation

G4 P2 Improve ICT maturity at centers

L1 P2 ICT Support, Training, Procurement

G2 P2 Rightsource ICT Services at Centers with a Global View

N3 P2 Cloud Computing - Utility Computing and SaaS

C1 P3 Develop a VoIP strategy for the CG system

G1 P3 Identify Critical ICT services supporting Science

L3 P3 Standards for Network Infrastructure and Security

N6 P3 CGIAR-wide Network Equipment contracts

L5 P3 Optimizing Wide Area Network Connections

N4 P3 CGIAR-wide VPN redeployment and update

N5 P3 CGIAR Security Operations Center

G8 P3 Establish Appropriate CGIAR-wide ICT Standards

N7 P4 IPv6 Strategy for CGIAR

A2 P4 Enterprise Application Framework

A4 P4 Lifecycle of Shared and Standardized Applications

A5 P4 Data Management and Collection Tools for Research


TOPIC AREA: Application Layer

OVERVIEW

The CGIAR Centers each operate their own ICT infrastructures. At the highest layer of these infrastructures are applications that support the work of the Center. These applications include a very wide variety of research tools and collaboration systems, as well as traditional back-office applications such as accounting, human resources, and purchasing.

This topic brief covers the use of applications within the CGIAR Centers and proposes specific action items designed to optimize the selection and sharing of applications, specifically common applications, within the Centers.

BACKGROUND AND RATIONALE

There are many reasons to consider common applications across multiple Centers, including similarity of purpose, CGIAR Research Programs (CRPs, formerly called "mega-programs") and shared locations, facilitating collaboration, exploring cloud-based services, and reducing capital and operational expenses. Most of these reasons are fairly obvious and have been evaluated in considerable depth already.

Similarity of Purpose: Although each of the CGIAR Centers is unique and operates in its own regulatory and administrative environment, there is also considerable commonality: each of the Centers is more like the other Centers than it is to a traditional trans-national enterprise. This suggests that major application acquisition in any area can be done more effectively by raising the level above the individual center.

CRPs/Shared Locations: The Strategy and Results Framework for the CGIAR proposes “CGIAR Research Programs” which will cross CGIAR Centers. [SRF] At the same time, Centers are choosing to co-locate with each other in some geographic areas. While the CGIAR Research Programs and geographically co-located Centers don’t require integrated cross-Center applications, there are obvious arguments on both the research and back-office sides of ICT to have common applications.

Facilitating Collaboration: As the research teams at the CGIAR Centers are engaged in related work (independently of the collaboration required by the CRPs), it is logical to encourage researchers to draw from a common research tool kit, to simplify future collaborative efforts both within the CGIAR and without.

Exploring Cloud-based Services: Software as a Service (SaaS) is a strong trend being explored by many enterprises. As Internet bandwidth increases and becomes more reliable at CGIAR Centers, the use of SaaS may make sense in both back-office and research computing areas, as well as with commercial office utilities such as as email and/or other related office suites, providing thin clients for users where appropriate. Utility Computing, another type of Cloud-based service, may also be useful for researchers needing high-performance computing for their work


Reducing Expenses: As with any asset, software has both capital and operational expenses. Sharing applications may reduce acquisition costs, training costs, maintenance costs, and allow some specialized applications to be made available to researchers in more Centers, however possible increases in end user support and technical support would have to be well thought out, so as not to incur further expenses.

ENVIRONMENTAL SCAN

The possibilities for shared application services have been explored extensively in the CGIAR Centers, especially in the back-office area.

OCS - One Corporate System

The “One Corporate System” initiative [OCS] is already working to develop a single back-office system (sometimes referred to as ERP, enterprise resource planning, or HIFAS, highly-integrated financial accounting system) for multiple Centers:

“The OCS Initiative is an inter-center bottom-up initiative that seeks to have CG centers working together to select and implement a [corporate] system … to create synergies and economies of scale by increasing centers negotiation power with vendors, reducing consulting and implementation costs, and by increasing center collaboration by sharing development and maintenance costs among centers.”

Given that the core module of the OCS is Project Management, scientists could take advantage of all project information provided and be able to use it to their advantage, being able to have vital information on hand at any time of their projects.

Other System-Wide Applications

Other system-wide applications are currently being incorporated in various centers, for example the Human Resources application HR4U is successfully being used by a few centers. Other centers may want to follow suit and incorporate this system-wide solution while the OCS initiative takes flight. These solutions are probably not exclusive of each other and can work together.

The CGXchange, built on top of Google’s cloud-based web services, is currently providing collaboration tools across the CG Centers.

Enterprise Architectures

The team preparing this brief also evaluated four Enterprise Architectures--Department of Defense [US] Application Framework, Zachman Enterprise Architecture, The Open Group Application Framework, and the Federal [US] Enterprise Architecture. A summary of these architectures is beyond the scope of this brief, but is available as part of the references. [Framework]

http://www.cgxchange.org/


Survey of Application Usage

As part of this topic brief, the ICT Roadmap group asked each Center to provide a list of applications in use in four areas: Financial/Administrative, Operations Management, Research and Data Management, and Publications Management. While the survey was not comprehensive and different Centers gave different levels of detail in their answers, several trends are visible: [AppSurvey]

1. Centers all have a mature set of applications running in traditional back-office roles, although there is little commonality, with Oracle eBusiness, SAP, Microsoft, and other tools all reported in use.

2. Operations Management functions such as travel management, project management and coordination, grant management, and business intelligence functions are sophisticated in about half the Centers, with multiple applications including both COTS (commercial, off-the-shelf) and custom-developed. The other half did not report having a sophisticated operations management application portfolio.

3. Research and Data Management applications are common across all Centers, with a few typical applications (ESRI GIS tools, SAS or SPSS statistical tools) in almost each Center. Centers reported as many as 37 different Research applications. The survey data suggest that Centers have extensive portfolios in this area.

4. Publication Management applications are less sophisticated. Many Centers reported library management applications, but there seems to be very little penetration of various collaborative tool kits (other than typical web content management systems, such as Drupal and Joomla) into the Centers.

5. Above and beyond the applications themselves, there is a big opportunity to provide a much more integrated data management system for applications to use. For example, CGIAR Centers make heavy use of surveys, but the survey data and results are not coordinated or linked. Researchers wondering whether they can use an existing survey or not are stymied by the lack of common or linked databases that can be searched. The theme of "data repository" appears many times in this document.

ACTION ITEMS

A1) One Corporate System

Deliverable: Support the selection and deployment of back-office software as part of the One Corporate System initiative. Investigate any bandwidth/connectivity requirements and integration with document management systems/corporate repositories that OCS will require when it is rolled out.

Business Need: The Background and Rationale in this document lists five reasons for shared applications. All of these are valid reasons to suggest a common back-


office framework for the CGIAR centers. The One Corporate System initiative is an "action item" which proposed a single, shared application to cover many back-office requirements. The Action Item here is an endorsement of the One Corporate System initiative and a directive to continue the standardization of back-office applications across Centers and, where possible, the creation of a shared back-office application to handle financial and administrative tasks.

A2) Enterprise Application Framework

Deliverable: Research Enterprise Application Frameworks in the context of the new Consortium to determine applicability to the CGIAR in the area of administrative applications. N.B. It is not anticipated that this would apply to research computing needs. Business Need: Enterprise Application Frameworks address the twin problems of increasing system complexity and decreasing business alignment within the information technology arms of large enterprises. In the context of this research, individual Centers are likely too small to require such an enterprise architecture or framework. However, as the Centers combine to a larger CGIAR Consortium, there is applicability of these frameworks to the larger organization. The goal of this task is to identify the areas where the research in Enterprise Application Frameworks can be applied to the CGIAR Centers to increase IT value while reducing IT costs.

A3) Common Data Repository for CGIAR Research Programs and beyond

Deliverable: In conjunction with appropriate partners within CGIAR, a Common Data Repository for CRPs should be developed, including data dictionary and with full access control/security capabilities. Both known data objects and potential future data objects should be supported. This action item has scope beyond CGIAR Research Programs (“CRPs”) as well, and may have results with broad applicability.

Consideration should be given to storing both structured (e.g., database) data and unstructured (e.g., publications, images) data in the Common Data Repository.

The Common Data Repository should be workflow-enabled, rather than simply being a repository for data and role-based with the possibility of having both public (uncontrolled) and private (authenticated, access-controlled) access.

This Action Item may be satisfied by making a single common repository (if there are few Center-wide repositories), or by creating a "virtual" repository that sits on top of existing repositories to create a single consistent view.

This Action Item should also consider using Storage as a Service as the core storage for the repository (“in the cloud” storage).

Business Need: The new CRPs will be generating large amounts of data that need to be managed. This is especially important with the new CRPs, because some information that is generated by one CGIAR-Research-program will be needed as input to another CGIAR-Research-program. The Common Data Repository will include common data dictionaries to describe the data collected, definitions of terms and specifications of allowable values, documentation of the data stored, and


version control for updates. An important part of this Common Data Repository will be the security of the shared data, both against unauthorized access and unauthorized modification.

As the work of the CGIAR gets re-organized into Research Programs, the work outputs for any Research Program will be spread across the institutional repositories that have been setup at multiple centers and are a major component of the One Corporate System (OCS) project to be adopted by as many as ten centers initially. The information in these repositories will need to be repackaged (virtually or physically) so that they not only reflect the institutional knowledge and memory but so that they also reflect the CGIAR’s research program history. The current reality of diverse, center-based repositories needs to merge seamlessly into the definitive collection for each research program.

A4) Lifecycle of Shared and Standardized Applications

Deliverable: A Procedure to deploy both Shared and Standardized Applications and a common methodology to deal with the lifecycle of applications.

Business Need: The action items within this brief, as well as other projects within the CGIAR Centers, call for applications to be either standardized or shared or both. We anticipate the benefits of shared and standardized applications, and want to encourage the creation of greater application standards and application sharing. This implies that a simple model to describe how applications are adopted, maintained, and eventually retired will reduce the costs of setting up new shared and standardized applications.

A5) Data Management and Collection Tools for Research

Deliverable: In conjunction with field users, this deliverable would include a report on new fieldwork data collection tools (mobile voice networks, text networks, tablet computers, Netbooks) across CGIAR Centers. The report would include an inventory of existing tools and devices in-use across the CGIAR Centers.

A second aspect of this deliverable would be guidance for end-users on the different data collection tools, including use cases to help users select the correct tools for their research.

Business Need: Multiple CGIAR Centers are investigating data collection tools that make use of newer technologies, including both hardware and networking. To reduce duplicate effort and work more efficiently, a CGIAR-wide investigation of the technology is appropriate.


TOPIC AREA: Communication & Collaboration Tools and Techniques

OVERVIEW

“Communication and collaboration tools and techniques” includes a broad set of ICT products and services, but some of the most fundamental are:

Synchronous Communications, including: a. Telephony and Audio conferencing b. Video conferencing c. virtual meetings d. Instant Messaging

Asynchronous Communications, including: a. Electronic Mail b. Collaboration platforms c. Social media and networking

Shared Repositories

These are core tools and techniques that can minimize the impact of distance on geographically dispersed team members, helping them work together more effectively.

In all of these areas, technology has changed extensively in recent years, opening up a broad range of possibilities to improve communications. The widespread availability of the Internet in most locations world-wide has made collaboration a more practical matter than ever before.

Even more significantly, the innovative forces behind collaboration tools (such as social media networks) are becoming more and more familiar to CGIAR researchers, making the use of these tools not just familiar, but an expected part of any day-to-day work plan. We are already observing the CGIAR research community exerting a substantial “pull” towards collaborative tools. The challenge facing the ICT community is how to bring collaborative tools to the CGIAR research community in a secure fashion. CGIAR ICT staff must ensure that the use of collaborative tools within CGIAR research teams operates in the best interests of the entire CGIAR community, providing a controlled, open and transparent platform to easily share and preserve information.

BACKGROUND, ENVIRONMENTAL SCAN, AND RATIONALE

Within the CGIAR system, the need for communication and collaboration tools and techniques is especially relevant for three reasons:


1. Most centers are highly decentralized so even intra-center teams are often geographically dispersed.

2. Most projects involve working with external collaborators. 3. Inter-center collaboration exists now and is likely to increase with the

reorganization into CGIAR Research Programs.

Though the IT units in all of the CGIAR centers are independent of each other, the CGIAR has a long history of ICT collective action focused on supporting communication and collaboration. The IVDN (integrated voice data network) was developed in the mid-90s to facilitate inter-center communication; the voice component of this is still in use at over half of the centers today and all centers participate in the common directory and email component. The CGVlibrary project successfully combined the library resources on all of the centers into a single, searchable collection; this is available at http://vlibrary.cgiar.org. The lessons learned in the initial attempt to develop a CGIAR intranet/extranet paved the way for the successful development of the CGXchange collaborative platform (http://www.cgxchange.org).

Institutional repositories -- a mechanism for collecting, preserving, and disseminating in digital form the work of an institution -- are described as a major component of the One Corporate System (OCS) project that will be jointly adopted by at least ten centers, although the focus of OCS has shifted towards back-office functions such as finance and administration and document management workflow functions. At this time, the OCS is not seen as a repository for research results so further work is required to collect the requirements for a collaboration platform and repository for OCS. [OCS]

But not all efforts have been successful; the pilot project using the Microsoft Live Communication Server (for instant messaging) was not embraced by all centers and the platform was dropped after two years.

There is much more that can be done to expand on this initial effort and CGIAR teams would benefit from having a robust set of communication and collaboration resources to choose from that are easy to use and well supported.

ACTION ITEMS

C1) Develop a VoIP strategy for the CGIAR system

Deliverable: Develop a unified VoIP strategy, and an implementation plan, for the CG system, including:

for Centers using analog or digital phones, technical standards to add SIP to PBXes; for Centers wishing to use full VoIP to the desk, technical standards for full VoIP PBXes and SIP interconnectivity

an overall architecture for VoIP based on SIP software standards, profiles, and if necessary acquisition of VoIP

clients to encourage VoIP

http://vlibrary.cgiar.org/



creation of gateways between popular proprietary systems, such as Skype, to bridge Center VoIP networks and encourage connectivity

linkage of Centres’ PBX system to enable least-cost routing of calls and inter-centre calling

standard procedures and promotion to encourage inter-center calling using SIP and a “communication culture”

standard procedures and promotion to encourage linkage to regional and country offices either using softphones or branch office SIP gateways to hosted or Campus based PBXs

directory services to allow easy discovery of phone numbers for CGIAR staff

external linkages to easily allow calls from non-SIP-connected parties, such as a button on a web page “click to call me”

integration of the CGIAR VoIP system with a cloud-hosted conference calling system/service

establishment of minimum standards for VoIP services, including investigation of proprietary extensions and their effect on connectivity

investigation of regulatory issues

Business Need: The introduction of CGIAR Research Programs (CRPs, previously called "mega-programs") will broaden the collaborative nature of the work of the CGIAR centers. Voice communication can help teams collaborate more effectively, but the lack of a “communication culture” within the CGIAR and in some cases cost and ease-of-use can deter a researcher from using voice. The original IVDN project begun in the mid-1990s addressed this by implementing a system that allowed all center headquarters staff to call each other as easily as a local call, but this has dwindled to only half the centers and, for the most part, never reached beyond headquarters offices. Changes in voice technology and the broad adoption of Skype have opened up new opportunities to revive and expand upon the original vision of no-barriers voice between CGIAR staff.

C2) Develop a collaboration and social media toolbox.

Deliverable: Make available to all CGIAR staff, support, and promote a collection of collaboration tools (locally hosted or cloud-based, as appropriate) including:

collaboration platforms o virtual meetings o wikis o shared workspaces (Google Apps, SharePoint)

desktop sharing large file transfer social media and social networking tools video/web conferencing audio conferencing


“Make available” in this context could include CGIAR-wide licensing, subscriptions to cloud-hosted services, CGIAR-hosted services, and so on, depending on the tools selected and the requirements. Where appropriate, paid services and enterprise versions of these tools should be selected (i.e., don’t just focus on free services). In the case of video conferencing and audio conferencing, CGIAR-wide subscriptions to bridge services may be appropriate if suitable vendors can be identified.

Another aspect of this deliverable is the creation of training materials and a decision tree or matrix for users to help them understand which tool to use in which situation (use cases). The training materials should be part of a continuing end-user support program, with regular updates.

The list of collaboration tools should be guided by the communication collaboration strategy of the CGIAR, and the set of tools should be selected with care to keep the variety appropriately contained. “Best Practices” for the CGIAR in the use of collaboration tools will be created, and maintained, as part of this deliverable.

This action item has several governance issues. One is an important tie-in between the use of collaboration tools and data/document knowledge management policies; the relationship between collaboration tools and long-term repositories within the CGIAR.

Business Need: Collaboration tools, including collaboration platforms (such as wikis, blogs, Google Aps, and Sharepoint), desktop sharing (such as GoToMeeting, webex and Dimdim), and file transfer systems (such as FTP and YouSend It) are widely used throughout the CGIAR system. Emerging tools, such as Yammer (company-private Twitter micro-blogging tool), are also seeing use by early adopters. Since teams have different needs—document archive versus joint document creation, for example—there is no one-size-fits-all tool that will meet all needs. CGXchange 2.0 has done a superb job in meeting many of the collaborative needs of CGIAR teams, but it alone cannot meet the needs of all of them. Centers have independently attempted to address the needs of their staff, resulting in an array of overlapping solutions. As inter-center collaboration grows, researchers will grow frustrated with having to master a different tool for each team. So the centers need to work together to identify, support, and promote the collection of tools that will meet the needs of staff without significant overlap.

People in many different locations and from different organizations are carrying out research projects. These projects and people require a platform and associated mechanisms for collaboration and joint work. As a side note: collaboration platforms require access control at the individual, group, and external/outsider level. The current CGIAR Active Directory does not easily enable access controls for external organizations. Changes or extensions to the directory may be necessary as part of this collaboration action item, and these have been identified as part of an Action Item in the Networking brief.


TOPIC AREA: ICT and Organizational ICT Governance

OVERVIEW

While the CGIAR is moving from a set of independent Centers to a more unified Research Entity, ICT in the CGIAR will also have to adjust from a set of independent ICT Centers to a more unified ICT Support function. Yet, there will be a need for regional and Local ICT specialized services.

There is also an opportunity for ICT to move from a simple support function to join the Business in researching ICT solutions to achieve the strategic objectives of the Organization. Stepping up the role of ICT will involve the adoption of well-defined ICT Governance policies and procedures.

Because the alignment of ICT with business needs and knowledge management is a widespread industry trend, many Centers have taken some or even many steps in this direction already.

As part of the new ICT governance it will be important to define the new role of the CEO and CIO along with a new Global ICT Services function. An external review on the ICT-KM Program in 2009 [ICT-KM-ExtReview] proposes several different structures for Governance. This will help support the consistent transformation of ICT groups across all Centers into an integrated ICT, information and knowledge function.

BACKGROUND, ENVIRONMENTAL SCAN, AND RATIONALE

Up to now, with the current Center’s independent status, ICT managers and senior management were in charge of taking all decisions. This includes decisions about the value of cooperation with other Centers, because the life of the Centers was mainly on each manager's own shoulders. This should not be the case anymore in a more unified CG where funds are distributed from a single entity. In this case, the CG is going to really look for economies of scale (as the study from Accenture points out) across multiple Centers. So if the CG is serious about economies of scale, the CEO and the CIO will have to take on higher profile roles which involve making ICT decisions and doing ICT planning on behalf of the Centers.

It is clearly an advantage from a business point of view that global ICT services currently with the ICT-KM Program would be expanded. It is also important that ICT units within each of the Centers continue and expand their expertise in the areas of information and knowledge management. It is felt that there is an ongoing trend for ICT in Centers to become more an expert and advisory service to guide staff on the best use of the technology for maximum cost efficiency. Local ICT would become less involved with running ICT operations and more with optimizing the workflow of staff and offices.


Staff should make sure that they get their project requirements ready, ask for the proper contract to service them and monitor results. ICT will be the intermediary that makes sure the right ICT services are chosen, the proper contracts setup and ensures deliverables are obtained. However, these ICT services should be, in large part, outside the local premises in the cloud or in the Enterprise cloud.

ACTION ITEMS

G1) Identify Critical Center ICT services supporting Science

Deliverable: A needs assessment for ICT services required by the science community, including all ICT services, not just those provided internally by CGIAR IT groups.

Consideration should be given to using the ITIL framework (such as the ITIL service catalog) in structuring this deliverable.

Business Need: Accenture did not have the resources or the time to look at the role of ICT in each center. IT needs to get involved in the planning of the entire spectrum of

(research) support services in the new CGIAR landscape. There are special ICT services provided to the Scientists and to the scientific community that are crucial to the success of research. It will be useful to find out if they are strictly local or if they can be globalized. Furthermore, some locally provided services could benefit from globalized support or globally provided tools.

G2) Rightsource ICT services at Centers with a global view

Deliverable: "Rightsourcing" is the process of identifying ICT services and applications, then deciding whether they should be delivered internally or handled using external service providers (with internal oversight). This deliverable has two parts: guidelines, and recommendations.

The CGIAR Centers, as the first part of this deliverable, should prepare guidelines on rightsourcing decision making along with a discussion of the elements required to guarantee service quality and continuity to the end users. For example, providing IT support to country offices might come with a service catalog, SLA (Service Level Agreement), performance metrics, and costs.

Further, once the guidelines on rightsourcing are developed, the second part of this deliverable calls for the guidelines to be used in a CGIAR-wide exercise. As part of this exercise, services will be identified that are common across multiple centers, and recommendations made about which should be kept internal to each Center, which can be fully outsourced, and which may be able to take advantage of an internal CGIAR service provider. N.B. “Global view” in this Action Item does not imply the same sourcing for all locations. However, the option for CGIAR Centers to collaborate because of proximity should be fostered.


Business Need: Rightsourcing of services aims for economic savings while providing the same or a higher level of service to end-users.

G3) Transform ICT from Service Provider to Strategic Partner

Deliverable: Recommend ICT goals and visions for the new CG systems that will be used as key messages to persuade senior management in championing organization-wide ICT transformation. Necessary steps (assessment, gap analysis, architecture definition, etc.) will be defined to a certain level of detail that can help facilitating the discussion, strengthen the case, and setting reasonable expectations.

Business Need: Modern IT management suggests that IT, in general, needs to be more closely aligned with the business it serves. This Action Item helps to promote IT into the position of best serving the CGIAR Centers.

Additional Background Information: As part of the discussion of this Action Item, the ICT managers offered guidance on direction and goals.

The ICT structure should be aligned with the business structure and organization and strategy. The organization and infrastructure needs to be flexible. We should align with internationally recognized frameworks like COBIT for governance to include oversight steering groups and ITIL for ICT Service Provision.

It needs to be clear which ICT Services are mandatory to be provided within the Consortium (either internally or externally with internal oversight). Requirements must be generated and agreed to by those who need the services. These can them be provided through a service catalogue and SLA by the ICT teams.

One option is to take ICT Services out of the Center structure. Since ICT functions are self-financing, they could be detached and still provide services back to the Centers and CRPs including partner organizations. (similar to ICT Services at ILRI and World Agroforestry). Country offices can then choose who they want to receive the service from: the closest ICT Service Unit, the ICT Service Unit that provides the service to the lead Center of the CRP, or from somewhere else.

G4) Improve ICT maturity at Centers

Deliverable: With the input of IT users, enterprise management, and the IAU, analyze the current ICT maturity level (see Appendix for a definition of "maturity level") at Centers, gather existing international maturity standards that would be applicable to CGIAR Centers, and recommend changes to help increase compliance with standards and increase overall ICT maturity.

This could be done in a fashion similar to the process followed by security auditors. However, it will require changes that have implications for the entire Organization and must be championed by senior management in Centers. Recommend that ICT within Centers adopt ITIL for the provision of services. One strategy for this may include benchmarking by comparing ICT maturity within Centers to Universities and similar organizations. This could provide a baseline as well as a target.


Business Need: Using tools such as COBIT (Control Objectives for Information and related Technology), identify measures, indicators, processes, and best practices to help maximize the benefits that ICT provides. These metrics can be used to carry out e-readiness assessments and gap analysis of each Center or CRP, providing both a baseline for future comparison and a measure against global standards for research centers. The goal of these types of assessments is to identify areas that need to be worked on (and, when repeated, documentation that improvements have been made).

Note that this is not a one-time project but a continuous process.

G8) Establish Appropriate CGIAR-wide ICT Standards

Deliverable: Explore areas where CGIAR-wide ICT standards would be beneficial, where these standards would further the goals of the CGIAR as a whole, and where standards would be valuable to the groups involved. Some of these standards might require coordination with other groups within the CGIAR. For example, while there is an ICT component in the following two example areas, they are not purely ICT standards:

- Defining policies regarding “branding” of CGIAR web sites and collaborative tools, including the use of logos and domain names

- Defining social media (internal and external) policies and guidelines

Some areas are more clearly purely within the remit of the ICT area, for example:

- Creation of good practice standards for application development

- Security guidelines for Active Directory - Requirements for ICT business continuity - Security requirements for 3rd party vendors - Tools to use to operationalize policies and guidelines

N.B. The areas listed above are meant purely as examples, and are not meant to be an exhaustive list for this action item. It is likely that ICT Standards will be a continuing action item, not a one-time project.

Business Need: Establishment of standards helps to reduce long-term costs and uncertainty within an organization. By providing guidelines in common areas of concern, standards enable groups to focus on the important work at hand and spend less time re-visiting decisions and discussions that have already been made.


TOPIC AREA: Location Strategies

OVERVIEW

In an era of extreme mobility, the concept of "being in the office" has disappeared for many knowledge workers. Today, being in the office may simply mean sitting in front of their laptop anywhere they can find a Wi-Fi signal. At the same time, in some cities, CGIAR Centers have chosen to co-locate with one another and with other partners. These twin trends of mobility and co-location give CGIAR staff great flexibility in where they work, but also raise important issues.

This topic brief focuses on ICT issues that are affected by a person's location, whether they are in their head office, a regional, country or project office, or traveling.


An implicit part of the CGIAR is that certain guiding principles should apply to all staff, no matter what their location. In the context of this brief, we believe this means that there should be equal access to resources wherever a person is located. This requires a minimum standard of connectivity and a security system that can authorize access across locations.

Obviously, not all locations will have the same capabilities, due to the realities of geography, politics, and budgets. However, when a minimum standard is set, this will provide guidance to applications and systems designers about what they can, and cannot, expect in the end-user community.

ENVIRONMENTAL SCAN

The ICT-KM Second Level Connectivity project investigated issues specifically related to smaller regional and country offices. Started as a project to improve connectivity to the internet, it soon became clear that there were several other issues limiting the effective use of ICT in the regional and country offices including poor support, old or non-existent equipment and infrastructure, lack of funding, information and training and poor collaboration with others. Many of the ideas from the Second Level Connectivity project have been used in the action items in this brief. See also [SLC Vision].

The NetHope project (www.nethope.org) is a project to increase collaboration among international humanitarian organizations. NetHope focuses on five initiatives, all collaborative in nature, including Connectivity, Field Capacity Building, Emergency Response, Shared Services, and Innovation. Information on NetHope is available on their web site and not generally in standalone documents.

CIAT has produced documentation for their Regional Offices focusing on Standards and Procedures. In the Standards area, Cabling Standards, Computer Room Cabling, and Electrical Protection are covered. Procedures are documented for Hardware and Software Inventory, Policies on Computer Use, Backup

http://ictkm.cgiar.org/what-we-do/project-archive/investment-plan-2004/second-level-connectivity/


Procedures, and Policies for Internet and Email. [CIAT-Procedures] [CIAT-Standards]

Other projects within the CGIAR and community that have looked at these location issues include:

CIFOR (Center for International Forestry Research)

www.cifor.cgiar.org

IDRC Acacia Initiative http://www.idrc.ca/acacia/

IDRC Connectivity Africa Infobook (2005)

[IDRC Infobook]

Balancing Act Africa http://www.balancingact-africa.com/ (commercial reports, not uploaded)

UN Economic Commission for Africa

http://www.uneca.org/ (although dated, the UNECA hosts dozens of publications on Information Technology for Development), [NICI eStrategies]

United Nations agencies have considered sharing locations carefully in the context of their "Delivering as One" project. The One Office piece of Delivering as One includes overview guidance documentation, as well as specific reports on the projects in Cape Verde, Mozambique, Pakistan, Rwanda, Tanzania, and Uruguay. [OneUN]

ACTION ITEMS

L1) Provide ICT Support, Training, and Procurement to Under-Served Offices

Deliverable: Create an ICT support organization, based on a clearly defined scope, for under-served CGIAR Centers based on a regional support model with local language capability. The scope of this deliverable is primarily offices that do not have local support, although this could be extended more broadly based on experience and capabilities.

This may also include development of a knowledge base and COPs, harmonization of procurement standards, desktop standards, standards for remote support tools, and general policies within a location or region to reduce variance between Centers.

Any support structure should also include reference to established international guidelines, most specifically the ITIL (Information Technology Infrastructure Library) framework for IT Service Management.

This deliverable also includes specific support for training, as in the following examples (which are not meant to be exhaustive or restrictive):

- face-to-face training


- virtual training - self (CBI) training - orientation (new employee) training - funding for support visits in remote areas.

Several issues to be addressed here include:

- structuring of costs and staff pay - accountability and reporting (who does this report to?) - governance of the support and training facility - selection of web-based tools for support

Business Need: Good quality ICT support at all locations within the CGIAR is critical to ensure effective use of systems and infrastructure. Because the CGIAR Centers have very similar ICT environments, there is considerable overlap in technologies and configurations. By moving support resources closer to the end-user, time zone and language differences can be minimized. At the same time, a higher level of training (with greater face-to-face or virtual training sessions and e-Learning tools) will make end-users more efficient in utilizing the resource available to them, head off potential confusion, and resolve support issues more quickly.

L2) Backup, Data Protection, Business Continuity

Deliverable: Establish CGIAR data backup systems focusing on the needs of under-served and small offices, including:

- a day-to-day automated solution (for disaster recovery or lost file recovery) based on either traditional software approaches or backup appliances,

- cloud-based backup services, especially for small offices, contracted at the CGIAR-level (not at the individual office level)

In addition, establish a CGIAR Storage As A Service contract (not dependent on a single vendor, though). This can help to mitigate risk in the development of disaster recovery packages

Business Need: Head offices of CGIAR Centers typically have full-time IT staff and the expertise to manage and maintain standard backup systems. In smaller offices, this is not the case and backups may be handled in a haphazard or ad hoc manner by staff who are not trained to ensure that systems are being properly backed up. A CGIAR backup solution will ensure that valuable data are not lost when disks crash or laptops are lost. This could be based on cloud services, or combined with a location storage system, and would be designed to be easily rolled out to smaller offices, replacing tools such as portable hard drives and never-replaced magnetic tapes.

A different, but related, issue is the loss of data from an institutional perspective when the data are being gathered and managed away from central IT facilities. To reduce the risk of loss, a CGIAR repository should be created to help capture information from all types of locations in a secure and protected fashion.


L3) Global Standards for Network Infrastructure

Deliverable: Establish minimum specifications, recommended equipment, and standard configurations (for different types and sizes of locations) to ensure network capabilities, configuration, and desktop security meets acceptable standards at all CGIAR locations. This includes both governance issues and technical standards, so multiple groups may need to contribute to the final result of this Action Item.

Some components of this deliverable may also be covered by the CGIAR Security Operations Center (proposed in another topic brief).

Business Need: In general, ICT infrastructure in larger campuses is established with a high level of network capabilities and security. However, in regional, country and project offices, the level of network infrastructure and the attention paid to security can be quite low, impeding access to critical resources, and putting the entire organization at risk through malware infection or unauthorized access. By establishing minimum standards and recommended configurations for networks across all locations, this risk can be reduced. In addition, standardization will reduce the costs of deploying secure networks and secure desktops by enabling knowledge re-use not just within a Center but also across all Centers.

L4) Internet Connectivity

Deliverable: Establish minimum standards for Internet connectivity, including guidelines for selecting vendors, media (wires/wireless/VSAT), and types of circuits.

Identify roaming service providers (such as iPass) for public Wi-Fi and GSM data services and establish CGIAR-wide contracts for best pricing.

Investigate CGIAR-wide e-mail and application gateway approaches with an eye to reducing capital and operational expenses and improving reliability.

Investigate emergency VSAT connectivity options with an aim towards setting up a "standby" contract for CGIAR offices in need of emergency connectivity. This item probably should be moved to the VSAT negotiation Action Item.

Policies should be established to encourage offices to keep their infrastructure to a minimum, to encourage co-location, and put budget monies into better Internet connectivity.

Business Need: Internet connectivity is crucial to the new way of working within the CGIAR. While smaller offices have investigated lower cost services, a lack of standardization and shared knowledge has resulted in sub-standard deployments in some locations. As sharing of infrastructure using Internet services becomes the norm, the quality of Internet connectivity will be a key predictor of success of location sharing projects.

As CGIAR staff travel, they also always need Internet access even when away from a CGIAR location. While pay-as-you-go services are always convenient, it is desirable to investigate global services providers that may result in lower overall


costs and possibly better connectivity. This applies both to Wi-Fi services and GSM-based telephone services, including gateway products such as BlackBerry Enterprise Server.

L5) Optimizing Wide Area Network Connections

Deliverable: Investigate and, if appropriate based on cost vs. benefit, establish a CGIAR-wide contract for WAN acceleration products and circuit aggregation products. Produce a report showing how these products could be used in the CGIAR and the expected benefits and cost savings.

A second aspect of this deliverable is the investigation of alternative technologies to WAN acceleration, such as Windows 7 Branch Cache, and other software-based proxy or caching solutions.

Business Need: WAN Acceleration products can provide a better end-user experience over congested, high-latency, or bandwidth limited circuits, although at a cost. The use of these products within the CGIAR VPN or individual Center VPNs has no been fully explored. The unique nature of the CGIAR operating environment means that most publicly available test results and evaluations do not apply. A rigorous testing and procurement process could result in the availability of these valuable tools to the CGIAR ICT managers. By providing enterprise-wide testing, CGIAR managers can select products with a minimum of effort and maximum assurance of proper return-on-investment.


TOPIC AREA: Network and Telecommunications Infrastructure Services

OVERVIEW

Each CGIAR Center manages and maintains its own telecommunications network. While many of these networks are similar in design, the final responsibility for network design and operation has fallen on the individual Centers. In a more tightly connected CGIAR Consortium, many basic network and infrastructure services could be coordinated with a result of increased collaboration capability and reduced cost.

This topic brief covers a variety of areas where coordination between the CGIAR Centers is desirable in the areas of network layer services and telecommunications infrastructure. Voice over IP and digital telephony, topics which might be considered at this layer as well, are covered in the Collaboration Tools brief instead.


The network infrastructure within the CGIAR Centers is a core that all other ICT services depend upon. More and more, the research and results that the Centers produce requires 100% uptime of infrastructure services, including the network. For this reason, it makes sense to seek ways to: - increase the reliability of the network and the basic network services - monitor and manage the security of the network 24/7 - decrease the cost of running the network - provide a larger and more flexible set of network service building blocks

For many mid-size organizations, the operation of the network and network services such as Active Directory are secondary tasks of the ICT team--they don't necessarily take a full-time person's attention. Because networks, once set up, tend to run acceptably even in the absence of any active monitoring and management, ICT teams focus elsewhere. The end result is networks that slowly decay in performance, security, and reliability, and are often behind the capability curve when new demands are placed on them.

By bringing together the requirements of multiple Centers, many tasks that would not be affordable or reasonable for a single Center to accomplish can be shared among multiple Centers--and provide cost-effective benefits to all. This topic brief proposes eight specific initiatives to meet the goals of increasing reliability, security, and services at a cost-effective level.


ENVIRONMENTAL SCAN

A number of CGIAR-wide projects have focused on network layer and infrastructure services. These include the Active Directory project, and a project to coordinate use of anti-malware software across Centers.

In 2003, the CGIAR Centers migrated from their existing Windows environment to a coordinated Active Directory/Windows 2000 system. This installation, coordinated by CGnet, also included installation of Microsoft ISA proxy servers at each site and the creation of a shared Microsoft Exchange email network. Each Center runs its own Exchange servers, but the email directory is common as is the address space for users "@cgiar.org". While the Active Directory and ISA proxy server installation met many goals, the software and hardware are generally out-of-date. An existing project to upgrade Microsoft Exchange to Exchange 2010 is in operation beginning in 2011.

In 2008, the brief study was undertaken to consider the use of a single antivirus tool in the CGIAR. At that time, Trend Micro's anti-virus tool was in use in most Centers and the question considered was whether this was still the technical best solution. The conclusion of the study was that Trend's efficacy had suffered and several Centers had migrated to competing products, including ones from ESET, McAfee, and Kaspersky.

In 2008, a case study was undertaken to explore alternatives to the existing CGIAR collaboration system. At the time, a goal was to find a system that would not require too much investment in time and money. Because Google Applications, a suite of collaboration tools on the cloud (Software as a Service - SaaS) that includes calendar, chat, documents, sites, video and more, met the requirements of low initial investment, it was chosen as a pilot project. The study went so well that in early 2009 it was decided to replace BEA Aqualogics (CGIAR's former locally managed collaboration system) for Google Applications and the advantages of this change have been substantial.

ACTION ITEMS

N1) Active Directory

Deliverable: Continuing program of maintenance, education, and development of CGIAR Active Directory.

This deliverable would establish a funded program to:

- maintain the health of the directory, - to include outreach on existing training materials, - to create a knowledge base - to add a community of practice, - and develop new training materials to help CGIAR Centers make use of

this resource.



It should also be considered whether Active Directory should be opened up for use beyond the current Windows Domain Controller and Email/Exchange uses, and if this is agreed, then any required changes to routing, replication, and access methods should also be implemented. At the same time, additional services such as DNS may be added (for health checks, training, etc.).

Additions to Active Directory as part of this action item would also include a way to access the GAL (Global Address List) of Exchange outside of the Exchange environment, but within the CGIAR using protocols such as LDAP.

This deliverable should include a review of current design or Active Directory alternatives, to determine if the design is still optimal given changes in organizational direction and hosting environments.

An additional action item within this would include a governance policy explicitly addressing the sharing and/or replication of Active Directory information between CGIAR centers.

Business Need: Active Directory provides a critical service for the CGIAR. The CGIAR-wide Active Directory is not providing the best service possible to all Centers. One of the reasons for this is simple neglect--there is no continuing program to maintain the health of the directory and resolve problems. While there are some "best practices" provided by CGnet, in practice, the individual Centers do not have the expertise or privileges to keep the directory operating optimally. In addition, it was found that Centers are not making good use of the common directory and authentication service because of lack of training in programming and operation of the directory. The lack of a properly working directory can impact end-user productivity, cause interruptions in service, and decrease total system security.

N2) Enterprise Single Sign-On infrastructure

Deliverable: An enterprise single sign-on infrastructure that includes the following:

- based on open standards; not necessarily based on AD - integrated with the CGIAR Active Directory (or its successor) - ability to include partners and a non-CGIAR user base

When rolling out systems that integrate with SSO, a governance requirement for a risk/security analysis should also be included.

Because the single sign-on system would be a superset of the existing Active Directory authentication and directory service, the scope of single sign-on may require Active Directory to be expanded to include giving non-CGIAR collaborators access to resources that require authentication. This could be done, for example, by creating an authentication service that integrates CGIAR Active Directory and another directory through tools such as OpenID, SAML, and OAuth.

Business Need: CG Centers have traditionally used internally run applications that would only require an initial logon by the staff. Currently, there is increasing demand for SAAS (Software as a service) and applications running in the cloud.


These applications require logging into foreign systems that do not rely directly on the CGIAR Directory services. To avoid users having to remember several passwords, increase security, staff efficiency and establish license-tracking mechanisms it is critical that the CG adopts an ESSO system. This will be an extremely useful tool to identify applications where economies of scale can be applied through Centers. This system should be centrally hosted and managed in collaboration with the Centers.

N3) Cloud Computing - Utility Computing, Outsourced Services, and SaaS

Deliverable: Identify specific areas where Utility Cloud Computing, Software-as-a-Service Cloud Computing, Platform-as-a-Service Cloud Computing, and other Outsourced Hosting and Management can be used within CGIAR Centers.

This deliverable includes the following:

- establishment of policies and good practices to encourage Centers to move to SaaS and Utility Computing/PaaS as a default deployment strategy, to define security in the use of cloud services, including data protection and compliance, and to define inventory control to ensure that cloud-based services have a defined lifecycle to reduce “sprawl.”

- specific review of the existing Email network to consider whether email should be outsourced in some way (ranging from on-premises to off-premises hosted)

- scan CGIAR environment to identify back-office applications (finance and administrative) that can be moved to the cloud, such as the existing OCS initiative;

- scan CGIAR environment to identify areas where research computing can make use of both SaaS and utility computing. Examples of this might include bio-informatics, remote sensing, GIS (geographic information systems), and modeling;

- identify areas where outsourced management of applications or systems would benefit the CGIAR centers

This deliverable should include a white paper or other explicit discussion of the constraints that would prevent Centers from joining cloud services or infrastructure changes such as increased bandwidth that may be required before cloud services can be effectively used (a “reasons not to go to the Cloud” white paper)

Business Need: SaaS and Utility Computing promise to provide lower costs to enterprises by taking advantage of massive economies of scale that can be offered through service providers. While there are significant issues of control and data security that have "clouded" the use of these new computing delivery techniques, there are many other areas where cloud computing can offer fast deployment, high degree of scalability, excellent reliability, global levels of accessibility, and significant cost savings. This is both true in the SaaS area (for example, the CGIAR is already using Google's cloud-based services for information collaboration) and in utility computing (which will be of primary interest to researchers needing high


performance computing). (Readers needing additional background information on SaaS and Utility Computing should refer to the Appendix of this document.)

N4) CGIAR-wide VPN redesign, firewall upgrade, and filtering options

Deliverable: The CGIAR-wide VPN should be updated to meet current needs. This deliverable would include several basic requirements:

(1) redesign of the CGIAR VPN to separate out the VPN from the firewall functionality to provide a more appropriate locus of control

(2) consider options to replace the ISA servers with low-cost firewall appliances to support the VPN

(3) design a standard for Web caching, malware detection, and URL filtering to replace the ISA functionality in Centers that want proxy-type web filtering. Support of IPv6 should also be built-in at this point.

Business Need: The CGIAR VPN was originally developed to share Active Directory information using a combination web proxy/VPN/firewall product developed as Microsoft ISA running on general-purpose computers. Enterprises rarely use this technique today. As the original ISA software and hardware is now badly outdated, a re-design of the VPN to use less-expensive, more reliable and more capable hardware is appropriate. In addition, because the combination of firewall+VPN+proxy in the same device has been problematic for some Centers to manage, and has restricted greater use of the VPN for information sharing, a separation of function that will allow each piece to operate independently offers a greater value to the Consortium as a whole. Models for VPN deployment, including central administration or distributed administration, should be explored to find the "best fit" with current use of firewalls and VPNs within individual Centers.

N5) CGIAR Security Operations Center

Deliverable: Creation of a CGIAR Security Operations Center (SOC), either using in-house resources or outsourced to a MSSP (Managed Security Service Provider).

The responsibility of this SOC would be to handle day-to-day operations in the area of network security for Centers, including monitoring any IDS/IPS (intrusion detection/intrusion prevention) systems, updating firewall configurations and software, monitoring firewall logs, managing threat mitigation tools such as network anti-malware. The SOC would also monitor multiple security alert bulletins to summarize and report regularly to CGIAR network managers on emerging threats and any urgent patches or updates.

Because the SOC would be applying uniform standards across multiple centers, there is a substantial Governance component to this Action Item. The SOC must be linked to security policies established by ICT Governance. The SOC would promote solutions to the CGIAR Centers that help them to adhere to the CGIAR Security Guidelines.


Because anti-malware products and patching products have variable efficacy rates, an important part of this action item would be regular re-evaluation of the desktop protection and patching vendors being used in the CGIAR to ensure that the tools are providing effective protection (or patch management, as appropriate) in all environments.

The SOC would also have a long-term audit function to ensure that proper security is applied across the CGIAR Centers. As part of the audit, the SOC would promote solutions to the CGIAR Centers that help them adhere to the security guidelines.

Another aspect of this action item is a regular update schedule for the CGIAR Best Practice security documents, since without regular updates they would not be useful.

Business Need: Few Centers, if any, have networks that are large enough to support a dedicated SOC function. However, all have networks connected to the Internet and a constant flow of systems in and out of their network. Most have also suffered one or more security problems in varying degrees of severity. Because there is no full-time support, security is a 'part time' job for many Centers, increasing the possibility that an intrusion or infection will interrupt work or cause data loss. By combining the resources of multiple Centers, a SOC can be established (or contracted with through any number of Managed Security Providers, MSPs) to provide this increasingly required service at a low cost to Centers who wish to make use of it. It should be noted that previous Enterprise Security and Internal CGIAR audits have already recommended the creation of a SOC.

The CGIAR has already begun work on enterprise-wide “best practices” in the area of network security ([EnterpriseSecurityDocs]), which help demonstrate the demand from Centers to improve their security posture.

N6) CGIAR-wide Equipment and Training contracts

Deliverable: Investigate, and if appropriate, negotiate contracts for IT equipment and training globally for CGIAR Centers.

This would include typical devices from the vendors most-used within the CGIAR Centers, including:

o Networking Equipment: switches, firewalls, and routers o Systems: desktops, laptops, and servers o Specialized Equipment: PDAs, mobile phones, ruggedized systems o Training

Challenges such as stocking of replacement equipment and geographic support issues will have to be included in any contract to facilitate world-wide buying and support. A side-effect of this Action Item might be greater standardization of equipment across CGIAR Centers.

This action item should also include an investigation of training alternatives. For example, internal IT training on common equipment could be provided by


CGIAR staff in conjunction with an equipment vendor or third-party training provider.

Business Need: Negotiating individual pricing contracts for each of the CGIAR Centers for products such as routers, switches, and firewalls is a significant time waster that adds to total costs and reduces the agility of CGIAR Centers. While the buying power of the Centers may not be significant globally, it is likely that advantageous pricing can be identified that at least reduces the requirement to run separate supplier bids and establish individual contracts with each supplier at each Center.

N7) Strategy for IPv6

Deliverable: A CGIAR-wide strategy for IPv6, including:

- any governance guidelines related to acquisition of IPv6-compatible network equipment, including a moratorium on purchasing equipment incompatible with IPv6

- a training program to inform network teams within the CGIAR on how to migration to IPv6

- a strategy for migration to IPv6 including long-term coexistence

Business Need: IPv4 IP addresses are essentially unavailable, limiting the growth of networks that require IPv4. As the CGIAR Centers link to each other “behind the firewall” using tool such as VPN tunnels, address collision may require the re-addressing of networks to ensure unique addresses are used within the entire CGIAR. IPv6 is the declared migration strategy by the IETF.


Participating ICT Managers

This roadmap was created through the collective work of more than 18 individuals. The main contributions were driven by the ICT managers of the CGIAR, CGIAR’s CIO (Enrica Porcari) ,with additional coordination and guidance from Tania Jordan (Office of the CIO) and Joel Snyder (External consultant, Opus One).

Center ICT Manager

Bioversity Dario Valori

CIAT Carlos Meneses

CIFOR Muhamad Robby Munajat

CIMMYT Carlos Gabriel Lopez

CIP Edgardo Torres (Acting IT Manager)

ICARDA Colin Webster

ICRAF Ian Moore

ICRISAT Pradyut Modi

IFPRI Nancy Walczak

ILRI Ian Moore

IRRI Marco van den Berg

IWMI Nirudha Perera

WARDA Moussa Davou

WorldFish Rainelda Ampil

Roadmap development started in 8/July/2010 and continued electronically until 28/September/2010, when all teams had submitted their first drafts of action items for the Roadmap. A second draft based on comments was presented to the ICT Managers on 7/October/2010. At the annual ICT manager’s meeting, held in 2010 in Addis-Ababa, Ethiopia, the roadmap was discussed in face-to-face meetings the week of 11/October/2010. A final draft and prioritized list of action items were output documents from the Addis meeting on 14/October/2010.

The final version of this roadmap was prepared on 22/November/2010.


References

[SLC Vision] ICT-KM Second Level Connectivity Project: Improving Communications and Access to Internet Resources for CGIAR Regional and Country Offices. (uploaded to ICT-Roadmap Location Site)

[IDRC Infobook] Connectivity Africa Infobook (downloaded from http://www.idrc.ca/acacia/ev-89542-201-1-DO_TOPIC.html) (uploaded to ICT-Roadmap Location Site)

[NICI eStrategies] National Information and Communication Infrastructure (NICI) e-Strategies. Best Practices and Lessons Learnt (2006) (downloaded from http://www.uneca.org/aisi/nici/documents/nici-book.pdf) (uploaded to ICT-Roadmap Location Site)

[EnterpriseSecurityDocs] Enterprise Security Good Practice documents include seven “Good Practice Guides” and an accompanying set of checklists. These include:

Email Management and Security Internet and Email Acceptable Usage Policy Internet Security Network Infrastructure Security Network User Identification and Authentication Sensible Use of Bandwidth Workstation Security

( downloadable from http://www.cgxchange.org/ict-infopoint/es-security-good-practices )

[CIAT Procedures] CIAT Information Systems Unit: "Regional Offices IT Procedures" (uploaded to ICT-Roadmap Location Site)

[CIAT Standards] CIAT Information Systems Unit: "Standards and Recommendations for Regional Office Infrastructures" (uploaded to ICT-Roadmap Location Site)

[OneUN] Multiple documents, downloaded from http://www.undg.org/index.cfm?P=1213 and http://www.undg.org/index.cfm?P=1214. Uploaded as a single archive to ICT-Roadmap Location Site)

[OCS] One Corporate System documents: http://ocs.cgxchange.org

CG Systems - Existing Systems Comparison (November/2008) CG Systems - Lessons Learned (November/2008) OCS General Requirements OCS Key Questions OCS Concept Document for Rome Meeting (August/2009) OCS Technical Requirements (all downloaded from www.ocs.cgiar.org/July/2010)

[SRF] Strategy and Results Framework documents:

http://www.cgxchange.org/ict-infopoint/es-security-good-practices

http://www.cgxchange.org/ict-infopoint/es-security-good-practices

http://ocs.cgxchange.org/


A draft Strategy and Results Framework for the CGIAR (March/2010 Background Document and FAQ document for Consultancy on Common Administrative, Financial, and Research support Services in the new Consortium of the CGIAR Centres Design and Establishment of the Consortium of CGIAR Centers - Final Report (October/2009) An AHP-Expert Choice Model for the Strategic Results Framework of the CGIAR (Executive Summary by Mueller and Stricker) Key Findings and Recommendations from the Consultancy on Common Administrative, Financial, and Research support Services in the new Consortium of the CGIAR Centres (November/2009)

[Framework] Application Layer Frameworks

Department of Defense (US) Application Framework v2 (volumes 1-3) Federal Enterprise Architecture Framework Consolidated Reference Model v2.3 The Open Group Architecture Framework v9 Zachman Framework structure for Enterprise Architecture Comparison of the Top Four Enterprise Architecture Methodologies by Roger Sessions

[AppSurvey] Survey on Application Deployment within the CGIAR Centers (August/2010) (http://hyperlink/here)

[ICT-KM-ExtReview] External Review of the Information and Communications Technology and Knowledge Management Program (ICT-KM) of the Consultative Group on International Agricultural Research (Sept 13, 2009) (http://ictkm.cgiar.org/document_library/program_docs/External_Review_09/ICT-KM%20External%20Review%2009.pdf)

http://hyperlink/here


Appendices

The information in this section is supplementary and includes documentation of the discussions of the team who prepared this brief, as well as other background material that may be helpful to the reader.

Maturity Model: A Definition

One of the action items in this brief uses the term "Maturity Model." The following definition may be helpful for readers who have not come across this term before. This is taken from a web site improvementandinnovation.com.

"Maturity relates to development and growth, from an initial state to an advanced state, with various implicit stages in-between that need to be travelled through in order to reach the advanced state. In the context of business change/improvement, the initial state would be the implementation of the program, and the advanced state one where the strategies of the program have been fully adopted and integrated into the organization on an ongoing and robust way.

Mapping the cycle of maturity provides a framework enabling an organization to gauge the health of its program by providing a point of reference for its current state, and then consequently guide the future direction of the program by setting and prioritizing goals, aligning functions and projects, and setting a method for future appraisal. This is the Maturity Model. It gives the leadership a method of measuring and reviewing the progress of an improvement program.

A Maturity Model is usually created based on benchmarking research carried out with various companies. It seeks to answer two vital questions: Why do some improvement initiatives succeed, while others fail? What is it that successful programs do differently? Consequently, the correct utilization of a maturity model can help greatly in ensuring that an improvement program is on the right path to success."

COBIT: A Definition

COBIT is an oft-mentioned (in this brief) term. The following definition may be helpful for readers who have not come across this term before. This is taken from the Wikipedia article on COBIT.

"The Control Objectives for Information and related Technology (COBIT) is a set of best practices (framework) for information technology (IT) management, created by the Information Systems Audit and Control Association (ISACA) and the IT Governance Institute (ITGI) in 1996. COBIT provides managers, auditors, and IT users with a set of generally accepted measures, indicators, processes and best practices, to assist them in maximizing the benefits derived through the use of

http://en.wikipedia.org/wiki/Information_technology

http://en.wikipedia.org/wiki/Information_Systems_Audit_and_Control_Association

http://en.wikipedia.org/wiki/Management

http://en.wikipedia.org/wiki/Audit

http://en.wikipedia.org/wiki/User_%28computing%29

http://en.wikipedia.org/wiki/User_%28computing%29

http://en.wikipedia.org/wiki/Measurement

http://en.wikipedia.org/wiki/Business_process


information technology, and developing appropriate IT governance and control in a company.

COBIT was first released in 1996. Its mission is “to research, develop, publicize and promote an authoritative, up-to-date, international set of generally accepted information technology control objectives for day-to-day use by business managers and auditors” [1]. Managers, auditors, and users benefit from the development of COBIT because it helps them understand their IT systems, and decide the level of security and control that is necessary to protect their companies’ assets, through the development of an IT governance model.

COBIT 4.1 has 34 high-level processes, covering 210 control objectives, categorized in four domains:

1. Planning and Organization 2. Acquisition and Implementation 3. Delivery and Support 4. Monitoring and Evaluation

COBIT provides benefits to managers, IT users, and auditors. It provides managers with a foundation upon which to base IT-related decisions and investments, while ensuring continuous service and monitoring system performance.

Decision-making is more effective because COBIT aids management in:

1. Defining a strategic IT plan 2. Defining the information architecture 3. Acquiring the necessary IT hardware and software to execute an IT

strategy

IT users benefit from COBIT because of the assurance provided to them by COBIT's defined controls, security, and process governance.

COBIT benefits auditors by helping them to identify IT control issues within a company’s IT infrastructure. It also helps them corroborate their audit findings."

Enterprise Architecture: A Definition

One of the action items in this brief uses the term "Enterprise Architecture." The following definition may be helpful for readers who have not come across this term before. This is taken from a document "A Comparison of the Top Four Enterprise-Architecture Methodologies" by Roger Sessions.

Twenty years ago, a new field was born that soon came to be known as enterprise architecture. The field initially began to address two problems:

1. System complexity—Organizations were spending more and more money building IT systems; and

http://en.wikipedia.org/wiki/Internal_control

http://en.wikipedia.org/wiki/COBIT#cite_note-0


2. Poor business alignment—Organizations were finding it more and more difficult to keep those increasingly expensive IT systems aligned with business need.

The bottom line: more cost, less value. These problems, first recognized 20 years ago, have today reached a crisis point. The cost and complexity of IT systems have exponentially increased, while the chances of deriving real value from those systems have dramatically decreased.

Today's bottom line: even more cost, even less value. Large organizations can no longer afford to ignore these problems. The field of enterprise architecture that 20 years ago seemed quaintly quixotic today seems powerfully prophetic.

Many enterprise-architectural methodologies have come and gone in the last 20 years. At this point, perhaps 90 percent of the field use one of these four methodologies:

1. The Zachman Framework for Enterprise Architectures—Although self-described as a framework, is actually more accurately defined as a taxonomy

2. The Open Group Architectural Framework (TOGAF)—Although called a framework, is actually more accurately defined as a process

3. The Federal Enterprise Architecture—Can be viewed as either an implemented enterprise architecture or a proscriptive methodology for creating an enterprise architecture

4. The Gartner Methodology—Can be best described as an enterprise architectural practice

This white paper discusses these four approaches to enterprise architecture. It does so within the context of a fictional company that is facing some very nonfictional operations problems. These problems include:

IT systems that have become unmanageably complex and increasingly costly to maintain.

IT systems that are hindering the organization's ability to respond to current, and future, market conditions in a timely and cost-effective manner.

Mission-critical information that is consistently out-of-date and/or just plain wrong.

A culture of distrust between the business and technology sides of the organization.

How should this company choose from among these four very different approaches to enterprise architecture? This white paper traces the journey the company is likely to face in using any one of these methodologies.

When examining each of these methodologies in depth, one is struck by the fact that none of these approaches is really complete. Each has strengths in some areas and weaknesses in others.


For many enterprises, none of these methodologies will therefore be a complete solution. For such organizations, this white paper proposes another approach, one that might be called a blended methodology. Choose bits and pieces from each of these methodologies, and modify and merge them according to the specific needs of your organization. This white paper gives an approach to creating such a blended methodology that is a best fit for your organization's needs.

But even a blended methodology will only be as good as an organization's commitment to making changes. This commitment must be driven by the highest level of the organization. The good news is that, with a real commitment to change and a tailored methodology for guiding that change, the 20-year-old promise of enterprise architecture is within reach.

That promise hasn't changed: reducing IT cost and complexity, while increasing business value and effectiveness—or, to put it even more simply, improving your competitiveness in an increasingly competitive world.

Unified Communications: A Definition

One of the action items in this brief uses the term "Unified Communications." The following definition may be helpful for readers who have not come across this term before. This is taken from the web site "UCStrategies.COM."

What is Unified Communications?

Unified Communications (UC) has many definitions, so don’t get stuck on this. The results from UC are what matter, not the definition. As was well said in a panel at VoiceCon San Francisco 2008, "Let's quit arguing about what UC is; let's spend our time focusing on what UC actually does."

UCStrategies.com defined UC from the outset in 2006 as:

“Communications integrated to optimize business processes.”

We continue to see this as a sound foundational definition. This integration of communications can occur across a wide spectrum, from:

Users simply adjusting their habits, to Manual integration as defined by procedures and training, to Integration of communications into off-the-shelf tools such as

Outlook, Notes, BlackBerry, Salesforce.com, and many others, to Purpose specific integration into customized applications in specific

operating departments or in vertical markets such as healthcare.

Two Types of UC Applications

Given this range of possibilities, two categories of the UC definition were defined in 2007-2008:


UC-User Productivity or UC-U: Unified Communications tools that users adopt to improve their experience and/or results.

UC-Business Processes or UC-B: Unified Communications tools that are explicitly integrated into defined processes, either procedural or automated.

This diagram illustrates how UC-U and UC-B cover a continuum from personal through workgroup through enterprise-level adoption and scope.

The definition includes "optimized" since the tools and techniques of UC enable transformative changes in an enterprise’s operations (business processes):

For-profit companies can earn more revenue with less cost and greater profits

Non-profit organizations can lower costs while improving service delivery

In both cases, the operations are significantly improved by changing how communications tools are used and by eliminating communication-related “hot spots” – those places where the operational activities are blocked, delayed, or complicated by communications issues.

UC Applications

These Application Descriptions provide an overview and supporting details for each of the five UC-Business Process (UC-B) Application Groups defined below. In addition, there are Application Descriptions for three (3) UC-User Productivity (UC-U) Applications Groupings.

These application descriptions can be used in all phases of UC implementation. They are valuable when evaluating which applications are most applicable to your business; they are useful for your UC and communications planning; and they can be used for discussion of UC opportunities with the operational management of your enterprise (Line of Business, Agency Leaders, etc.).


UC Applications can be categorized as UC-U (User Productivity) and UC-B (Business Process). In both categories, we can observe that the applications are appearing in five major application groups. As with any groupings, there will always be exceptions and outlying examples, but these five groups provide a guideline on where to look for the applications in your enterprise.

The five application groupings are:

Contact Management – Facilitating access from clients, partners and associates

Resource Identification and Problem Resolution – Finding a skilled, authorized person or team and solving a problem

Seamless Information for Mobility – Delivering access communication and information to mobile personnel, seamlessly

Collaboration Acceleration – Helping teams get creative and project work done most expeditiously

Communication-enabled Job Portals – Packaging communications right into the user's workflow and application tools

Note that none of these Application Groupings are a product or technology. Rather they are solutions based on "communications integrated to optimize business processes," our basic UC definition.

The required products and technologies are different for each of the Applications Groupings.

UC Applications

UC-B Applications

Contact Management – Facilitating access from clients, partners and associates

Resource Identification and Problem Resolution – Finding a skilled, authorized person or team and solving a problem

Seamless Information for Mobility – Delivering access communication and information to mobile personnel, seamlessly

Collaboration Acceleration – Helping teams get creative and project work done most expeditiously

Communication-enabled Job Portals – Packaging communications right into the user's workflow and application tools

UC-U Applications

Basic UC Productivity – Enhancements via Presence, Instant Messaging (IM), and Click-to-Communicate, where the communications are via the UC software, independent of a PBX or IP PBX; usually these solutions co-exist with PBX-type systems.

Advanced UC Productivity – Basic UC productivity plus mobility solutions; voice, web and/or video conferencing; usually collaborative workspaces, and some from of integration with legacy or new PBXs or IP PBXs and the telephone network.

Enhanced Voice UC Productivity – The extension of Voice over IP (VoIP) and IP PBXs to include Basic and/or Advanced UC Productivity tools, offering some additional savings in total cost of ownership and selected user productivity tools.

http://www.ucstrategies.com/uploadedFiles/UC_Resources/Contact%20Management%20UC%20RFP%20Templates%20Solution%20Description%20v9-8-1.pdf

http://www.ucstrategies.com/uploadedFiles/UC_Resources/Resource%20Identification%20and%20Problem%20Resolution%20UC%20RFP%20Templates%20Solution%20Description%20v9-8-1%281%29.pdf

http://www.ucstrategies.com/uploadedFiles/UC_Resources/Seamless%20Info%20for%20Mobile%20Personnel%20UC%20RFP%20Templates%20Solution%20Description%20v9-8-1.pdf

http://www.ucstrategies.com/uploadedFiles/UC_Resources/Collaboration%20Acceleration%20UC%20RFP%20Templates%20Solution%20Description%209-8-1.pdf

http://www.ucstrategies.com/uploadedFiles/UC_Resources/Job-Specific%20Comm-Enabled%20Portals%20UC%20RFP%20Templates%20Solution%20Description%20v9-8-1.pdf

http://www.ucstrategies.com/uploadedFiles/UC_Resources/Basic%20UC%20Productivity%20Tools%20RFP%20Templates%20Solution%20Description%209-8-1.pdf

http://www.ucstrategies.com/uploadedFiles/UC_Resources/Advanced%20UC%20Productivity%20Tools%20RFP%20Templates%20Solution%20Description%209-8-1.pdf

http://www.ucstrategies.com/uploadedFiles/UC_Resources/Enhanced%20Voice%20UC%20Productivity%20Tools%20RFP%20Templates%20Solution%20Description%209-8-1.pdf


Cloud Computing: A definition

One of the action items in this brief uses the terms "Cloud Computing", "Software as a Service" (SaaS), and "Utility Computing." The following definitions may be helpful for readers who have not come across these terms before. This is taken from a white paper prepared by Joel Snyder.

What is Cloud Computing?

Cloud computing is based on a single premise: you don’t need a computer room to make use of a computer. Cloud computing offers the benefits of rapid scalability—the ability to get very big, very fast—as well as high reliability and high degree of accessibility. Cloud computing also has the potential to reduce costs, by outsourcing many aspects of operation of business applications.

The roots of cloud computing extend to the first days of computers, when mainframe computers were rare and expensive. In those days, companies would “rent time” on computers operated by service bureaus to run different applications. Cloud computing was one of the original reasons for building the Internet: so that researchers at one University could use computers at a different school.

Fast forward to the era of personal computers and the Internet, a ubiquitous world-wide telecommunications network. While some of the original premises of cloud computing have changed—for example, except for certain super-computers, the cost of computing hardware is very low—others have taken their place. Computer hardware may be cheap, but the people to keep it running are as expensive now as they ever were. The Internet may let people come to your data easily, but certain types of applications, such as wide-spread video streaming, require very specialized networks beyond the reach and expertise of most companies.

Types of Cloud Computing

Today, Cloud Computing is broadly broken into two categories: software-as-a-service (SaaS), and utility computing. In the diagram nearby, traditional business computing can be easily compared to these two types of Cloud Computing.

In Standard Business Computing, users connect to applications across the company network. The application software and supporting hardware are

Figure A Traditional computing uses company software, on company hardware, on the company's network. Cloud Computing leverages hardware and software owned by Service Providers, on the Internet


both fully under the control of the company. For example, in the CGIAR, the Email System at most Centers includes application software bought from Microsoft running on supporting hardware bought from server vendors such as HP, Dell, and IBM, all running in computer rooms owned and controlled by the Center.

In Utility Computing, a type of Cloud Computing, the user side of the equation is the same: organizational users connect to applications. However, instead of going across the company network, they connect across the Internet to a data center run by the Cloud Computing provider. On hardware provided by the Cloud Computing provider, the company installs and manages its own software applications. Utility Computing is most attractive to organizations that need to scale up their computing resources massively in a very short period of time. For that reason, it is common in new “startup” companies to use Utility Computing rather than build their own computer centers.

The second type of Cloud Computing, Software as a Service, is the predominant type of Cloud Computing used by businesses today. In SaaS, users connect across the Internet to software and hardware in a data center run by a cloud computing service provider.

Both types of Cloud Computing make use of "Cloud Computing" service providers. These are generally considered to be third party companies, such as Amazon or specialized providers such as CGnet. However, the CGIAR could build and manage its own "service provider" to provide Cloud Computing SaaS and/or Utility Computing within the CGIAR.


Single Sign-on: A Definition

One of the action items in this brief uses the term “single sign-on.” The following brief description is from The Open Group’s definition of Single Sign-On.

Introduction

As IT systems proliferate to support business processes, users and system administrators are faced with an increasingly complicated interface to accomplish their job functions. Users typically have to sign-on to multiple systems, necessitating an equivalent number of sign-on dialogues, each of which may involve different usernames and authentication information. System administrators are faced with managing user accounts within each of the multiple systems to be accessed in a coordinated manner in order to maintain the integrity of security policy enforcement.

Historically a distributed system has been assembled from components that act as independent security domains. These components comprise individual platforms with associated operating system and applications.

These components act as independent domains in the sense that an end-user has to identify and authenticate himself independently to each of the domains with which he wishes to interact. The end user interacts initially with a Primary Domain to establish a session with that primary domain, which requires the end user to supply a set of user credentials applicable to the primary domain, for example a username and password. The primary domain session is typically represented by an operating system session shell executed on the end user’s workstation within an environment representative of the end user (e.g., process attributes, environment variables and home directory). From this primary domain session shell the user is able to invoke the services of the other domains, such as platforms or applications.

To invoke the services of a secondary domain an end user is required to perform a Secondary Domain Sign-on. This requires the end user to supply a further set of user credentials applicable to that secondary domain. An end user has to conduct a separate sign-on dialogue with each secondary domain that the end user requires to use. From the management perspective the legacy approach requires independent management of each domain and the use of multiple user account management interfaces.

Benefits of Single Sign-On

Considerations of both usability and security give rise to a need to co-ordinate and where possible integrate user sign-on functions and user account management functions for the multitude of different domains now found within an enterprise. A service that provides such co-ordination and integration can provide real cost benefits to an enterprise through:


reduction in the time taken by users in sign-on operations to individual domains, including reducing the possibility of such sign-on operations failing

improved security through the reduced need for a user to handle and remember multiple sets of authentication information.

reduction in the time taken, and improved response, by system administrators in adding and removing users to the system or modifying their access rights.

improved security through the enhanced ability of system administrators to maintain the integrity of user account configuration including the ability to inhibit or remove an individual user’s access to all system resources in a coordinated and consistent manner.

Such a service has been termed Single Sign-On after the end-user perception of the impact of this service. However, both the end-user and management aspects of the service are equally important. This approach is illustrated in the diagram above. In the single sign-on approach the system is required to collect from the user as, part of the primary sign-on, all the identification and user credential information necessary to support the authentication of the user to each of the secondary domains that the user may potentially require to interact with. The information supplied by the user is then used by Single Sign-On Services within the primary domain to support the authentication of the end user to each of the secondary domains with which the user actually requests to interact.

Documents

CGIAR ICT Roadmap