August 2005
RESTRUCTURING OF THE ICPDR
INFORMATION SYSTEM
Final Draft
AUTHORS
PREPARED BY:
Miroslav Melisko
Restructuring of the ICPDR Information System
page 3
TABLE OF CONTENT
Table of Content ........................................................................................................... 3
Executive Summary....................................................................................................... 5
1.
Objective and Scope ........................................................................................... 7
2.
As-is status ....................................................................................................... 8
2.1.
The existing ICPDR structures and related work .................................................. 8
2.2.
Administration, user management and document management of
the current system ......................................................................................... 9
2.3.
Structure of the internal area of the Danubis ...................................................... 9
3.
Key issues to be addressed by the new/improved system........................................10
3.1.
Content of the Danubis...................................................................................10
3.2.
Document management and related functionalities .............................................10
3.3.
Navigation ....................................................................................................10
3.4.
Directory structure of the internal area .............................................................11
4.
System Architecture - Solutions...........................................................................15
4.1.
Solution 1 - Content Management ....................................................................15
4.1.1.
Implementation .........................................................................................16
4.1.2.
Administration ...........................................................................................16
4.1.2.1. Application level administration.............................................................16
4.1.2.2. System level administration .................................................................16
4.2.
Solution 2 Collaboration Portal + Content Management ....................................17
4.2.1.
Implementation .........................................................................................18
4.2.2.
Administration ...........................................................................................19
4.2.2.1. Application level administration.............................................................19
4.2.2.2. System level administration .................................................................19
4.3.
Solution 3 - Collaboration Portal + Workflow + Content Management ....................19
4.3.1.
Implementation .........................................................................................20
4.3.2.
Administration ...........................................................................................20
4.3.2.1. Application and system level administration............................................20
5.
Evaluation of solutions .......................................................................................21
5.1.
Implementation.............................................................................................21
5.2.
Estimation of implementation time ...................................................................21
5.3.
Complexity of implementation .........................................................................21
5.4.
Usage ..........................................................................................................22
5.5.
Evaluation of administration ............................................................................23
UNDP/GEF DANUBE REGIONAL PROJECT
Restructuring of the ICPDR Information System
page 4
5.6.
Overall evaluation..........................................................................................23
6.
Estimation of input for overall system management ...............................................24
7.
Tasks and profiles .............................................................................................25
7.1.
System Implementation Analysis and Development..........................................25
7.2.
System Operation..........................................................................................25
7.2.1.
Administration ...........................................................................................26
7.2.2.
Further Development..................................................................................26
7.2.3.
Information management............................................................................26
8.
Conclusions ......................................................................................................28
UNDP/GEF DANUBE REGIONAL PROJECT
Restructuring of the ICPDR Information System
page 5
EXECUTIVE SUMMARY
The objective of this report is to propose changes in architecture and functionality of ICPDR
Information System to improve overall efficiency of work and satisfaction of users. The main focus
is on the internal part of the system.
The report proposes:
>
key system functionalities to support information life-cycle and flows
>
restructuring of the current system in terms of main content navigation
>
architecture of system with key system functionalities, evaluation of possible solutions
and estimation of the system implementation
>
estimation of input needed for the system management
An extensive evaluation of the ICPDR Information System was done in 2004 by UNEP GRID/DEWA
Geneva, where a number of issues were identified.
The issues related to the document management, functionalities and navigation are addressed by
the proposed system architecture solutions:
1. Content
Management
This solution keeps existing system (functionalities like access to databases, Events,
Discussion Forums) and integrates Content Management (or previously known as a
Document Management) system by replacing all functionalities related to categorizing,
indexing, storage and retrieval of content/documents.
2. Collaboration Portal + Content Management
From technical point of view a portal can be defined as a Web-based application that
provides personalization and content aggregation from different dynamic sources and hosts
the presentation layer of information systems. Portal provides standardized interface for
applications and data sources to present its outputs to the users. Another important feature
of portal is a capability to arrange all portlets and other web page components into
customizable layouts, which can even more improve usability and user satisfaction.
3. Collaboration Portal + Workflow + Content Management
This solution is similar to Solution 2 in a sense of Content Management and Portal
functionality, but brings different approach in a way the particular activities are
implemented. Workflow assumes that and can be implemented only if well documented
processes are in place. In this case, every activity is only a one step in a process, which is
defined as a sequence of work steps that is intended to be completed in order to fulfil a
request that triggered the process. The workflow system ensures that all the processes are
executed as defined, automatically delivers of work between process steps in accordance
with defined conditions, accomplishes systems steps within process and provides data for
analysis of processes. From user's perspective workflow system simplifies the work because
all task, no matter the subject they are related to, are delivered into and managed in
unified interface similar to e-mail clients, where tasks can be opened, modified, rejected,
delegated and completed. Tasks can contain instructions what work has to be done, data
needed to complete the work and attached documents (which can be links to documents
stored in CMS). Having tasks delivered and routed automatically, users can focus only on
work to be done, there is no need for them to look for work in different places and take
care of routing the work after it has been finished.
UNDP/GEF DANUBE REGIONAL PROJECT
Restructuring of the ICPDR Information System
page 6
Overall evaluation is a combination of Implementation, Usage and Administration evaluations. The
weight of each item should be stated depending on specific requirements, but in general,
administration does not need any significant weight to be set on, so if money is the issue, more
weight will be on implementation and the Solution 1 is probably the right choice, as long as it is
acceptable that only current status will be improved.
If usability is really important, Usage gets more weight and solutions 2 and 3 should be considered.
Decision which one to chose should imply appraising of number and rate of changes of processes,
plans about future expansion and number of processes and users. Skilled decision can be taken
after the outputs from analysis will be available (analysis is foreseen as a first step in
implementation). But based on current level of knowledge solution 2 can be proposed to be
implemented as it still allows to implement workflow in the future, but it will also make some early
developed and paid portlets functionality obsolete.
More detailed requirements should be a part of analysis outputs and must be approved prior any
research for available systems is conducted.
The next issue addressed by this study is the Content of Danubis, where a decision of the ICPDR
will be needed with respect to the applications and databases, since they require development
costs and further maintenance (updates).
The requirements for the content of the Danubis will be the key condition for building up or
restructuring of the current main content navigation menu. This report gives also recommendation
on simplifying the existing structure, based on assumption that the internal area will be used for
working purposes of the ICPDR expert bodies and will serve also as a source for information
available in the public area. Information that is not directly used by the expert groups will not be
displayed in the internal area.
The following steps will be needed to do the reconstruction of the system:
>
Decision on the changes in the content of the system (if any!), in terms of databases
and planned applications
>
Restructuring of the main content navigation menu (at least partly)
>
Selection of the system architecture
>
Implementation of the system
The input needed for reconstruction of the main content navigation menu will depend on
complexity of the content and also if uploading of additional information will be included. It may
vary from 1 to 3 weeks. At the moment the directory structure can be changed only partly, i.e.
folders that are planned for transfer to the ICPDR public site should be still kept in the internal
area. This is because the public site is still under development and it is not available to other
experts of the ICPDR.
Input required for the system implementation will be 8 12 weeks of work of a specialised expert,
depending on the system architecture solution.
For the system operation, the expected general input would be (12 +28) days/year for system
administration and development and 132 days for information management.
UNDP/GEF DANUBE REGIONAL PROJECT
Restructuring of the ICPDR Information System
page 7
1. OBJECTIVE AND SCOPE
The objective of this report is to propose changes in architecture and functionality of ICPDR
Information System to improve overall efficiency of work and satisfaction of users. The main focus
is on the internal part of the system.
Proposed solution should be based on industry standards or at least widely accepted and used
technology (Open Source products are preferred) to ensure possibility of future functionality
enhancements and keeping the administration and maintenance as simple as possible.
The main tasks of this assignment were:
1. Review the background for the Information System:
>
the ICPDR structures and related information flows
>
administration, user management and document management of the current system
>
structure of the internal area of the Danubis ('site map')
2. Propose:
>
restructuring of the current system in terms of main content navigation
>
architecture of system with key system functionalities, evaluation of possible solutions
and estimation of the system implementation
>
estimation of input needed for the system management
UNDP/GEF DANUBE REGIONAL PROJECT
Restructuring of the ICPDR Information System
page 8
2. AS-IS STATUS
An extensive evaluation of the ICPDR Information System was done in 2004 by UNEP GRID/DEWA
Geneva, where a number of issues were identified, therefore the present report gives very brief
overview of the existing system and addresses the key issues already identified.
Originally the system was using Oracle Application Server +Portal and Oracle Database Server. The
ICPDR is now reconstruction the public area and instead of Oracle Application Server (including
Portal), the Apache Web Server and the PHP scripting language is used. Thus the current system is
using two platforms, that should be in the future either integrated or only one system should be
used.
2.1. The existing ICPDR structures and related work
The ICPDR has a number of Expert Groups, with individual work plans, that are dealing with
different issues and topics. Therefore each of the group has its specific features and task to be
completed.
However, there are certain similarities in the work of the EGs. Each of the group:
>
prepares work programme and has defined ToR,
>
holds regular meetings for which they have to prepare documents (agenda, minutes,
invitations, etc.)
>
produces documents (in word, xls, pdf, ppt)
>
comments on and approves documents
Technical experts of the Secretariat are also managing their groups in similar way of:
>
keeping contact list up to date
>
managing changes in members
>
keeping track of tasks
>
sending notifications about upcoming or missed dead-lines, etc.
In addition to the above mentioned, there are specific tasks carried by the EGs
>
operation of AEWS
>
operation of TNMN
>
databases and their functions (biological database, emission database, investment
database, etc.)
>
Danube GIS (foreseen)
UNDP/GEF DANUBE REGIONAL PROJECT
Restructuring of the ICPDR Information System
page 9
2.2. Administration, user management and document
management of the current system
The current system is administered by two persons:
>
an external consultant, for technical support and for specific tasks related to the system
development
>
Info/Admin officer, for the user management and general document management.
The user management covers creation of specific user groups with different access rights to the
system and keeping update of the address list. Usually all experts have read access to the whole
internal area, but the read access is restricted to their specific working folder.
The document management, under supervision of the Info/Admin officer, is task of the technical
experts at the Secretariat, since they are usually preparing documents (e.g. meeting minutes) to
be uploaded to the system. The members of the expert groups have also read-write access to their
relevant working area folder, but they do not upload documents very often.
2.3. Structure of the internal area of the Danubis
The current structure of the internal working area (after log-in) provides two types of information:
>
used only for internal purposes
>
available also for public
The structure is presented as a tree-type of structure with several levels, using several types of
navigation. The available folders cover a wide range of topics, that can be divided into three groups
according their administration, i.e. who is maintaining their content, so they are related to:
>
work of Permanent Secretariat (e.g. partly The ICPDR, Announcements, News Events)
>
technical/scientific work of the ICPDR expert bodies (e.g. partly Internal area, DABLAS,
Databases...)
>
general information (e.g. National Information, GEF, Links...)
The content of folders `The ICPDR' and `Internal Area' is partly overlapping (through links), since
part of information has to be available for public as well as for internal area, i.e. ToRs or meeting
summaries.
UNDP/GEF DANUBE REGIONAL PROJECT
Restructuring of the ICPDR Information System
page 10
3. KEY ISSUES TO BE ADDRESSED BY THE NEW/IMPROVED
SYSTEM
3.1. Content of the Danubis
The Danubis covers three forms of information: documents, databases, applications. The ICPDR
should make clear, what should be included in the system to satisfy needs of users and covers
requirements of the contracting parties of the Danube Convention.
In particular, this is related mainly to the applications and databases, since they require
development costs and further maintenance (updates). Therefore, clear questions to be answered:
-
what databases to be kept and further developed (TNMN, EMIS, Biological, JDS...)
-
what are the additional applications planned in terms of scientific information and reporting
(GIS, Moneris)
3.2. Document management and related functionalities
Most of the activities carried by the users, related to the document management are realized
outside Danubis for various reasons; some functionality is not supported by the system (i.e.
automated tasks and group members management) and some are not used by users even it is
available (i.e. check-in/check-out a versioning). So the new system, depending on requested scale
of solution, should cover also those functionalities.
In general the information system should offer a number of management applications. So the
question to be answered is:
-
what are the expected applications/functions in terms of management of the secretariat
and expert groups (e.g. calendar, team management, document management...). The
guideline for answer of this question can be found in the next chapter of this report.
3.3. Navigation
One of the major problems of Danubis to be solved by the new system is all-in-one navigational
scheme. It has to be changed by strictly separating groups of navigational elements and directory
structures in logical form and also in its visual presentation on web site and also by reorganizing
directory structure to provide an easy access to stored content.
Navigation scheme should consist of two main levels:
1. core web site navigation
usually located on top of each page
>
Home page (can be also presented as a logo)
UNDP/GEF DANUBE REGIONAL PROJECT
Restructuring of the ICPDR Information System
page 11
>
Login/Logout
>
Preferences content on this page depends on status of the user (logged in/ not-logged
in) and provides access to following functionality:
change user information (including password)
change notifications settings
set out-of-office status in case it is supported by the chosen solution (this item
can be a part of user information section, but it will be accessed more often than
the rest of the user data, so the user will have quicker access to this functionality
directly in "Preferences¨ section)
set
language
customize layout in case it is supported by the chosen solution
change style (if it will be required and available)
>
Help / About
2. main navigation menu
menu items depends on actual system and its functionality but it should, if necessary and not
available on ICPDR public web site, incorporate links to HTML documents, currently stored in
directory structure.
The use of the flash currently applied at the start of the site should be reconsidered, as it is slowing
down the access to the internal area.
3.4. Directory
structure
of the internal area
As mentioned before, the current information system has public and internal area. The public area
is sub-item of the internal area. Therefore, the internal area contains also information are not
directly related to the work of the expert groups, what makes the internal area overcrowded and
not easy for new users to navigate. In addition to that, the exiting navigation menu and sub-menus
(folders and subfolders) are not organized, e.g. by topics, alphabetically, etc.
There is a number of folders that are not active, i.e. they contains outdated information or at the
moment they are empty. Some of the folders are duplicated. A site map is missing.
The public site is now under reconstructions, in terms of look & feel as well as the content. The
information provided can be considered as static, i.e. only final version of information are available
and are not expected to change.
The internal area should be dynamic and used for working purposes of the experts. In some cases
information available in the internal area are displayed also in the public area. If any change is
done in the internal area, it should be automatically reflected in the public area. This is a case of
address lists of the HoDs.
General recommendation to the current directory structure can be done, based on assumption that
the internal area will be used for working purposes of the ICPDR expert bodies and will serve also
as a source for information available in the public area. Information that are not directly used by
the expert groups will not be displayed in the internal area.
UNDP/GEF DANUBE REGIONAL PROJECT
Restructuring of the ICPDR Information System
page 12
Recommendations for the current structure of the internal area are following:
Internal Area (the title will be cancelled, since this is internal area itself)
>
General discussion forum keep/renew!
>
ICPDR Meetings - keep
>
Permanent Secretariat keep / renew!
>
Expert Groups keep
>
Database Forms cancel (or move under databases)
>
Dablas II merge with DABLAS
DABLAS - keep
JDS Working Area cancel (this is only link)
The ICPDR
>
Joint Action Programme keep / transfer to the public area
>
Presidents and Delegations - keep
>
Permanent Secretariat merge content with `PS' in `Internal Area'
·
Library
·
Search in Library important!
·
Maps / Videos
·
Finance and Administration merge with F/A in Doc-centre
>
Expert Groups merge with the Expert Groups in Internal Area
>
Observers transfer to the public site
>
Legislation cancel (or reconsider, who is doing updates)
>
Doc-centre reconsider/clarify the concept
·
Basic documents keep (linked to the public area)
·
Finance and administration keep (linked to the public area) renew
·
Meeting Summaries cancel (meeting summaries to be kept with
corresponding meetings)
·
Annual Publications keep (linked to the public area)
·
ICPDR Annual Reports
·
WQ yearbooks
·
Danube Watch
·
Technical Papers (it is empty now)
>
ICPDR related activities transfer to the public area
·
Bystroe Canal
·
Website management move to `about' (it is empty now)
·
Ministerial Meeting move, keep with other ICPDR Meetings
·
Danube Days
·
ALCOA
UNDP/GEF DANUBE REGIONAL PROJECT
Restructuring of the ICPDR Information System
page 13
·
HoD Workshop - move, keep with other ICPDR Meetings
·
Coca-Cola
Announcements - keep
News Events re-name to calendar of events (news should be on the public site)
Databases keep / renew
>
Draft versions keep / renew
>
Members of DB Groups move, keep with other address lists (to be created)
>
Members of JM move, keep with other address lists (to be created)
National Information transfer to the public area
GEF transfer to public area
Working Folder cancel (or reconsider / related to the secretariat)
Links - keep
History keep / transfer to the public area
About keep / renew (folders: Training, Archive)
`Keep' means that the content of the folder should be also maintained within the internal area.
`Cancel' means delete folder.
`Renew' means update the content of folder.
There are several ways to build up the site map of the system. One of the possibilities is to follow
the working structures of the ICPDR as well as the key projects/activities of the ICPDR, where due
to cross-cutting of the content it is difficult to assign the activity to the existing groups.
An example of the site map, i.e. the main navigation menu is following:
ICPDR (folder maintained by the PS)
>
high level meetings (meeting documentation)
>
presidency and delegations (presidency exchange information)
>
address lists (HoDs, experts, observers)
>
secretariat (contact, finance....)
Expert Groups 1 (folder maintained by the relevant PS Technical Expert / assigned EG member)
Expert Group x (folder maintained by the relevant PS Technical Expert / assigned EG member)
Databases (each database maintained by relevant expert body)
>
Bucharest declaration database, Dablas, Danube Survey, EMIS, TNMN, ARS inventory,
Biological
UNDP/GEF DANUBE REGIONAL PROJECT
Restructuring of the ICPDR Information System
page 14
Projects
>
DABLAS / Joint Action Plan / Joint Danube Survey / Tisza investigation / (History-
rename!) / Aquaterra / Bioindicator study / Danubs / ALCOA / COCA-COLA / Bystroe
canal
Publications and documents
>
Basic documents / Annual Reports / Technical Reports / Danube Watch
Danube GIS
AEWS
DBAM
Calendar of Events (maintained by the PS)
Announcements (maintained by the PS)
Library and Archive (maintained by the PS)
(this is recommended folder, since the current EG structure will be changed but the documentation
from all meetings have to be available)
The new structure should use the content of the existing folders as much as possible. It would be
also useful to consider the structure of the public site. This is valid for the folder `ICPDR' in the
public site, since it is foreseen that the internal area will be using the same system as the public
area.
New folders and subfolders should be created only when it is ensured, that they will have some
content which is regularly updated. (There are some examples of folders that are empty or it is
obvious that they are not updated.)
The input needed for reconstruction of the main content navigation menu will depend on
complexity of the content and also if uploading of additional information will be included. It may
vary from 1 to 3 weeks.
At the moment the directory structure can be changed only partly, i.e. folders that are planned for
transfer to the ICPDR public site should be still kept in the internal area. This is because the public
site is still under development and it is not available to other experts of the ICPDR.
UNDP/GEF DANUBE REGIONAL PROJECT
Restructuring of the ICPDR Information System
page 15
4. SYSTEM ARCHITECTURE - SOLUTIONS
Based on information collected during analysis and problems and proposals stated in assessment of
the ICPDR IS Danubis, three types of possible solutions will be evaluated:
1. Content
Management
2. Collaboration Portal + Content Management
3. Collaboration Portal + Workflow + Content Management
4.1. Solution 1 - Content Management
This solution keeps existing system (functionalities like access to databases, Events, Discussion
Forums) and integrates Content Management (or previously known as a Document Management)
system by replacing all functionalities related to categorizing, indexing, storage and retrieval of
content/documents.
Standard functionality provided by CMS is:
>
directory structure support for creating nested directory structure with possibility of
setting security rights for stored documents on directory level. Some systems uses
directory structure as another way of logical document categorizing, allowing one
document to be placed in more than one directory, i.e. contract can be stored in
Contracts directory and in the corresponding project directory at the same time.
>
Access rights to documents and directories managed on user and group of users levels.
>
Check-in/check-out functionality - to provide a secure way to work with documents for
several users. After the document is checked out by a user who is editing it, other
users can only read the document, until it is not checked in back to the system.
>
Versioning system keeps previous versions of the document available for author or
any user with appropriate access rights and the latest version is available for the rest of
the authorized users. Multilevel versioning supports also minor versions numbering
(1.0, 1.1, 1.2, 1.3, 2.0)
>
Document types with related meta-data document types are used to categorize
documents and meta-data are descriptors about actual content of categorized
document. This is basic functionality of CMS, because users are mostly looking for one
particular document and this type of categorization allows users to find it very quickly.
>
Search - most important part of CMS. Search engines allows users search for
documents by its names, types, meta-data or within a content of the documents by
full-text search. Access rights of the user are applied to the results so the user can not
see the documents he has no right to.
More options are available within CMS, like:
>
keeping records of physical documents
>
support for review and approval processes
UNDP/GEF DANUBE REGIONAL PROJECT
Restructuring of the ICPDR Information System
page 16
4.1.1. Implementation
First step of implementation will be analysis, which will describe all currently used documents,
processes related to documents and the way CMS can be integrated into existing platform. Outputs
from analysis will be later used for initial setup of CMS parameters, like:
>
basic and simple directory structure reflecting org. structure of ICPDR more detailed
directory structure can be defined to meet special requirements of each group; security
rules set on directories will automate access rights management, because the
document stored in specific directory can inherit security from its parent directory. So if
directory will have Read/Write access for technical expert and Read access for the rest
of the group, document uploaded into directory will automatically inherit those access
rights.
>
document types and its meta-data defined according to analysis held during
implementation; document types are applicable across the system which ensures that
all users will use the same categorization and the same document type (i.e. meeting
minutes) will have the same meta-data (i.e. meeting number, date of meeting) and will
be available for search. This can effectively reduce the need for complex directory
structure, i.e. document type "Annual Report", with "Year" as a one of the meta-data
indexes makes obsolete usage of directory dedicated for storage of such documents (as
it is in navigation menu in Danubis). In this case, specific annual report can be found
by specifying the year within the search criteria or all annual reports accessible by user
can be found by searching for document type without any meta-data specified.
>
Users and groups of users defined in accordance with org. structure and roles the users
are dedicated to. I.e. technical experts can have read access to documents from other
Expert Groups, or the group members can have a role of reviewer in review/approval
process for documents created within their group.
>
Review and approval processes will be set up according to actual or optimized and
standardized processes
>
Changes in existing system to integrate CMS and to remove obsolete functionalities
4.1.2. Administration
4.1.2.1.
Application level administration
There are no regular tasks expected on this level after initial setup of system. Occasional activities
like managing users (adding new user, changing security policy), content types (adding new
content type) are not time consuming and can by accomplished within minutes. Depending on
technical skills of person responsible for application administration even modification of review and
approval process can be done on this level, but some kind of basic change management should be
in place to ensure all changes are made in correct manner.
4.1.2.2.
System level administration
System availability
Availability of the system defines how many hours per day the system must be available for users.
Usual system availabilities are 5x8, 6x9 (working days and Saturday, from 8:00 to 17:00) or 24x7.
The rest of the time can by used by system administrators for backup or any other, in advance
UNDP/GEF DANUBE REGIONAL PROJECT
Restructuring of the ICPDR Information System
page 17
announced, tasks, which causes system outage, like implementing new functionality or updating to
a new version of software.
Expected administration time: no time, but affects others administration activities and initial
hardware and software setup.
System administration
Regular activities on this level depends on implemented system, what can be expected are
periodical checkouts of log files, available space in database and/or on disks. These activities can
be more or less automated, depending on operating system.
More administration work will be needed in case of upgrade to a new version or implementing new
functionalities.
Expected administration time: matter of minutes in day to day tasks, hours in upgrades and
implementations.
Backup & Restore
Plan for backup and restore must be in written form and approved by responsible persons from
ICPDR and ITU. B&R plan should have been approved only after successful test of plan with
significant testing data. The test of B&R plan must be realized before the system is in production
state.
B&R plan should contain description of backup procedure, backup schedule and step-by-step
instruction for data recovery.
Types and schedule of backup should be stated depending on the defined system availability and
size of the data.
Expected administration time: several minutes a day needed for backup tape management
4.2. Solution 2 Collaboration Portal + Content Management
From technical point of view a portal can be defined as a Web-based application that provides
personalization and content aggregation from different dynamic sources and hosts the presentation
layer of information systems.
Portal provides standardized interface for applications and data sources to present its outputs to
the users. A component responsible for communication with underlying application or data source
on one side and with the portal and users on the other side is called a portlet, i.e. portlet for user
interaction with database-based application, where the user is presented with an interface, created
by portlet and presented on portal, allowing him to specify search criteria; sending these criteria to
the application, receiving results and showing them in portal. But portlet itself can provide whole
required functionality if there is no application existing or the functionality is not very complex, i.e.
calendar.
Another important feature of portal is a capability to arrange all portlets and other web page
components into customizable layouts, which can even more improve usability and user
satisfaction.
UNDP/GEF DANUBE REGIONAL PROJECT
Restructuring of the ICPDR Information System
page 18
In a case of ICPDR we are talking about a group of geographically distributed users accessing the
portal via Intranet using their login names and passwords, which is usually referred as an extranet.
Depending on implemented system users can access the portal not only from traditional Internet
browsers installed on PCs but also from wireless devices, like PDA or mobile phone.
Using JSP technology ensures investment protection, because developed portlets can be used in
any portal supporting this technology; not only in Open Source but also in commercial products.
4.2.1. Implementation
According to previous explanation, two main systems will need portlets to be developed to
communicate with users via portal:
·
content management in a functionality scope described in solution I, with user interface
for:
·
searching and browsing directory tree for documents;
·
uploading and downloading documents with check-in/checkout and versioning
functionalities
Many portals solutions already contains portlets for content management, but these are
mostly oriented on web content management, not document management. If document
management is available, probably no or very little development will be needed. Even if no
content management is provided for chosen portal solution, thanks to portlets
standardization it is possible to integrate virtually any content management solution, but
more extensive development should be expected. If interface for administration is not an
integral part of the portlet, native interface should be kept to save implementation time
and money. At least a link to this interface should be available within portal or portlet for
authorized users.
·
databases interface providing simple (predefined, mostly used search criteria
combinations) and advanced search; reporting; upload data to be imported. Again, for
administration purposes, native interface of access to databases should be kept.
Exact functionality of another portlets covering activities listed in chapter 2.1 should be defined
during implementation in a functional specification following an analysis, but assumed functional
groups could be:
·
teams management nominating a new member for a group the user is in; accepting or
deleting a member by TE; searching for a member; modifying members data;
·
meetings management agenda and meeting minutes preparation and approval,
automatic distribution of invitations, registering, meeting tasks creation and assignment;
·
tasks management - assigned by other members as a results of activities done in portal or
by user himself. Functionality like list of tasks, sorting capabilities, accepting, rejecting,
changing status and delegation of tasks, notification about events and tracking of dead-
lines can be expected;
Additional no-portal-can-be-without functionalities like calendar, news/events board and discussion
groups can be implemented.
UNDP/GEF DANUBE REGIONAL PROJECT
Restructuring of the ICPDR Information System
page 19
4.2.2. Administration
4.2.2.1.
Application level administration
Scope and time of administration on this level is almost the same as in Solution 1. Little more time
can be needed to setup new user but this is only occasional activity.
4.2.2.2.
System level administration
Regular activities on this level depends on implemented system, but in general, time spent on
administration is comparable with Solution 1, content management and database tasks are the
same in both solutions. Administration of portal and underlying application server can by slightly
more time consuming than Oracle application server and web content in day to day tasks (matter
of minutes), but is easier on occasional broader changes and implementation of new functionalities.
Expected administration time: matter of minutes in day to day tasks, hours in upgrades and
implementations.
4.3. Solution 3 - Collaboration Portal + Workflow + Content Management
This solution is similar to Solution 2 in a sense of Content Management and Portal functionality, but
brings different approach in a way the particular activities are implemented. While in solution 2 the
activities are grouped in a subject oriented manner (team management, meeting management),
workflow assumes that and can be implemented only if well documented processes are in place. In
this case, every activity is only a one step in a process, which is defined as a sequence of work
steps that is intended to be completed in order to fulfil a request that triggered the process.
Examples of simple processes are:
- document approval, where the request starting the process can be an event of uploading a
new version of document into content management and following steps are: review of
document by all group members; approval by all group members; approval of technical
expert; publishing of final version;
- new member nomination, where the triggering action can be posting of filled-up web form
(available only for logged users) with next steps: check and approval by technical expert;
creating new user by system administrator; confirmation message sent to the new member
and requester;
The workflow system ensures that all the processes are executed as defined, automatically delivers
of work between process steps in accordance with defined conditions, accomplishes systems steps
within process and provides data for analysis of processes.
From user's perspective workflow system simplifies the work because all task, no matter the
subject they are related to, are delivered into and managed in unified interface similar to e-mail
clients, where tasks can be opened, modified, rejected, delegated and completed. Tasks can
contain instructions what work has to be done, data needed to complete the work and attached
documents (which can be links to documents stored in CMS). Having tasks delivered and routed
automatically, users can focus only on work to be done, there is no need for them to look for work
in different places and take care of routing the work after it has been finished.
UNDP/GEF DANUBE REGIONAL PROJECT
Restructuring of the ICPDR Information System
page 20
4.3.1. Implementation
Scope of implementation of portal, content management and development of portlets for CM and
databases is the same as in Solution 2.
The major difference is in development of the rest of the functionality. Implementation of workflow
should be preceded by identifying, describing and approving of all to-be-implemented processes in
paper form, which will be used as a reference for defining processes in the system.
The workflow system should be integrated into portal (some open source systems provides only
workflow engine; interface has to be build from scratch). Integration should cover creating user
interface to work with assigned tasks (if it does not exist), communication with CMS (if documents
stored in content management will be part of process) and other portlets (i.e. posted new member
nomination form will start process with data from the form). Last part of implementation of
workflow is to define and set-up of processes.
4.3.2. Administration
4.3.2.1.
Application and system level administration
Both levels are practically the same as in Solution 2, the only difference is in modifying processes
defined in workflow. Depending on technical skills of application administrator and competency
definition, these changes can be done on any level. Such modifications can also be done externally
if extensive customization or additional development is needed.
Expected administration time: matter of minutes in day to day tasks, hours in upgrades and
implementations
UNDP/GEF DANUBE REGIONAL PROJECT
Restructuring of the ICPDR Information System
page 21
5. EVALUATION OF SOLUTIONS
5.1. Implementation
Implementation consists of several phases: analysis, functional specification, customization and
development, testing, initial set-up and deploying. What can be compared are general estimations
about a time needed to have system up and running and complexity of development; both items
can affect overall price.
5.2. Estimation of implementation time
Solution 1 analysis & functional specification about 3 weeks; customization & development about
3 weeks; testing and deploying about 2 weeks; total 8 weeks
Solution 2 - analysis & research with proposal of specific system(s) about 4 weeks; functional
specification about 2 weeks; customization & development about 4 weeks; testing and deploying
about 2 weeks; total 12 weeks
Solution 3 - analysis (including analysis and description of processes) & research with proposal of
specific system(s) about 4 weeks; functional specification about 2 weeks; customization &
development about 4 weeks; testing and deploying about 2 weeks; total 12 weeks
All estimations are based on one dedicated full-time analyst (for analysis, research and co-
operation with developer on functional specification) and one dedicated full-time developer (for
functional specification, development, customization, testing and deployment), with project
managed by ICPDR person.
5.3. Complexity of implementation
Solution 1 there is no special need for development in core content management functionality,
only customization and set-up will be necessary; changes will be required in code of existing
system to modify navigation scheme and to integrate content management into web site
structure
Solution 2 most complex part for development is meetings management, because it will cover
different functionality like working with documents stored in CM, assigning new tasks, sending
invitations, etc.. The rest of the portlets should also be developed, mostly from scratch, but their
functionality is not complicated, i.e. members management is extended contact list with several
built-in functions. Implementation of portal itself is quite simple and straightforward task,
installation, layout setup and portlets integration are usually well documented.
Solution 3 Comparable with solution 2, less complex in portlets development but interface for
workflow should be developed as well.
UNDP/GEF DANUBE REGIONAL PROJECT
Restructuring of the ICPDR Information System
page 22
5.4. Usage
Summary of functionality covered by all solutions:
Solution 1
Solution 2
Solution 3
Managing documents
Content Management
Content Management
Content Management
and Workflow
Managing group
N/A New
functionality
Solved by workflow and
members
developed
development
Managing meetings
N/A
New functionality
Solved by workflow and
developed
development
Database access
Existing functionality
New interface
New interface
kept
developed
developed
(same as Solution 2)
Collaboration tools
Existing functionality
New interface
New interface
kept
developed
developed
(same as Solution 2)
Solution 1
- can be effectively used to solve main problems identified in current system, like navigation and
directory structure.
Solution 2
- same as Solution 1 but brings improved usability and more automation in day-to-day tasks for
users; JSR-168 specification compliancy ensures future compatibility and investment protection,
because existing portlets can be used (or bought and used) and portlets developed upon ICPDR
needs can be used in any compliant portal solution and possibility of future expansion to another
areas of use, like web content management.
Solution 3
- the same level of usability as solution 2, but even more automation and control over work than
previous solution; easier and quicker changes in processes than Solution 2, because some of the
modifications can be done by modifying the process definition and no development is needed this
advantage is applicable if several changes of processes per year are expected, if extension of
functionality or expansion noted in previous chapter will be planned or if new users are added
frequently (a training time can be significantly reduced in this case).
UNDP/GEF DANUBE REGIONAL PROJECT
Restructuring of the ICPDR Information System
page 23
5.5. Evaluation of administration
Application level
All solutions are comparable in a sense of amount of time spent by administering the system at this
level. The type of work slightly differs from solution to solution, but, in general, the tasks like
managing users and security and changing system settings will be done no matter the system and
the time needed for such administration will not demand dedicated full-time administrator.
System level
Having system up and running all solutions will need approximately the same time for
administering the system. Occasional activities can have different demands for time to be spent to
accomplish them, but it has no significant impact to overall evaluation.
5.6. Overall
evaluation
Overall evaluation is a combination of Implementation, Usage and Administration evaluations. The
weight of each item should be stated depending on specific requirements, but in general, as
described in previous chapter, administration does not need any significant weight to be set on, so
if money is the issue, more weight will be on implementation and the Solution 1 is probably the
right choice, as long as it is acceptable that only current status will be improved. If usability is
really important, Usage gets more weight and solutions 2 and 3 should be considered. Decision
which one to chose should imply appraising of number and rate of changes of processes, plans
about future expansion and number of processes and users. Skilled decision can be taken after the
outputs from analysis will be available. But based on current level of knowledge solution 2 can be
proposed to be implemented as it still allows to implement workflow in the future, but it will also
make some early developed and paid portlets functionality obsolete.
Main must-have requirements for proposed solution are:
- All applications or systems used in solution must be Open Source or any other freely
distributable licensing model
- Portal solution must be fully compliant with JSR-168 specification
- System must support for Oracle database
- Content Management system with support for directory structure, user defined
document types and meta-data, search (optional full-text); CM already integrated with
portal or existing portlet is preferred
More detailed requirements should be a part of analysis outputs and must be approved prior any
research for available systems is conducted.
UNDP/GEF DANUBE REGIONAL PROJECT
Restructuring of the ICPDR Information System
page 24
6. ESTIMATION OF INPUT FOR OVERALL SYSTEM MANAGEMENT
Assuming that the system is well implemented, with all required functions, the system
management tasks can be divided into two groups:
>
Maintenance system level administration (ensuring the system availability, s-w
upgrades, bugs fixing, backup and restore)
>
Development application level administration (user management, databases updates,
document management)
Considering the current content of the system and practices related to document management of
expert bodies, the required input for keeping the system up-to-date can be estimated as follows:
Regular Tasks
Man/day Input (minimum)
System maintenance
12 days (1 day per month)
TNMN database updates
5 days
EMIS Inventory updates
10 days
Biological database updates
10 days
AEWS communication
3 days
User management
12 days (1 day per month)
User support and system development
24 days (2 day per month)
General document management
18 days meetings only
78 days (1.5 days per week, incl. public site)
Ad-hoc
tasks
JDS related activities (foreseen in 2007)
15 days
New PIAC set-up (foreseen in 2006)
3 days
General document managements is related to preparation (web publishing) of documents for the
ICPDR high level meetings and similar events, what is now under direct responsibility of the
Info/Admin Officer of the ICPDR, as well as documents that should be made available at the public
site.
Further development tasks (ad-hoc tasks) may be expected only if additional functionalities are
required. This would be the case of integration of the Danube GIS into Danubis, which is now under
development. Other example is development of an interface for using MONERIS and DBAM in the
system.
The expected general input of a system administrator is about 12 days/year, developer 28
days/year and input of an information manager is 132 days.
UNDP/GEF DANUBE REGIONAL PROJECT
Restructuring of the ICPDR Information System
page 25
7. TASKS AND PROFILES
7.1. System Implementation Analysis and Development
The first step in implementing of an information system is analysis and consequent proposal on
functionalities that should be provided by the system. The analysis is focused on all processes and
information flows related to the operation of the secretariat and work of the expert groups. It
means that the analysis should focus on the practices used at the secretariat in the following areas
>
meeting management
>
team management
>
document management
>
usage of the databases and applications
>
existing or requested data flow between internal site and public web site
The analysis will result into recommendations, defining the functionalities that the information
system should have.
A company or an individual doing the analysis should have the following profile:
>
experience in analysis for software development
>
experience in processes analysis and description, optionally process optimization
>
knowledge about open source portal solutions and document management systems
Following the analysis and recommendations for required functionalities, the next step is
development of the system in terms of implementing and customizing chosen portal solution,
development of required functionalities and integrating into existing infrastructure. The required
qualification of the system developer is following:
>
Knowledge of the development methodologies
>
experience in Java development
>
experience in developing of JSR-168 compliance portal solutions and customized
portlets development
7.2. System Operation
After the system is implemented, its all functions are tested and fully operational, there is a need
to carry out system maintenance and operation. There are three groups of tasks to be carried out:
>
System level administration (back-up, restore, troubleshooting, bugs fixing, s-w
updates)
>
Application level administration (development of additional or improvement of existing
functionalities of the system, database updates, etc.)
>
Information Management (higher level of application level administration)
UNDP/GEF DANUBE REGIONAL PROJECT
Restructuring of the ICPDR Information System
page 26
7.2.1. Administration
In standard systems the first two groups of tasks are separated and that is also the case of the
Danubis. (The system administration is taken by the ITS of the VIC.)
As already outlined in the chapter 6, the basic required input for the System Administration is
estimated at 1 day per month. (Actually, this is a subject of an agreement with the ITS at UNOV).
7.2.2. Further
Development
In case of the Danubis, administration at the application level can be considered as development.
The estimated input for the development is about 28 days (~2.3 day / month). More input may be
needed if some tasks related to additional system development are too extensive, These additional
tasks have to be well planned and agreed at appropriate level of the secretariat management.
Required qualification of the administrator on the system and application level:
>
knowledge and experience with linux based open source application and web servers
(Linux, Apache, MySQL, PHP)
>
experience in Java development
>
experience in developing of JSR-168 compliance portal solutions and customized
portlets development
>
experience in administering and work with Oracle database server and its tools
7.2.3. Information
management
The tasks carried out by an Information Manager related to the operation of the Information
System would be:
>
manage documents stored in content management system, with particular attention to
the ICPDR high level meetings
>
keep an overview/manage the content structure of the system (in internal and public
area)
>
user management (in terms of assigning the user names, groups and access rights)
>
manage documents related to events, in particular the event calendar
>
identifies, analyses and propose actions for further development / improvement of the
Information System at the level of the Secretariat management as well as work of the
expert groups
>
provide support to new EG members or PS staff on use of the system
>
ensure coherency of information available at the internal and external area
UNDP/GEF DANUBE REGIONAL PROJECT
Restructuring of the ICPDR Information System
page 27
The required qualification of the Information Manager in relation to the Information System would
be:
>
experience in meeting, team and information management and familiarity with best
practices used in international organizations of similar size
>
basic knowledge about users, access rights and their relationship
>
basic knowledge in using and/or managing web based applications
>
excellent knowledge and ability to work with the MS Office Professional and Windows
As mentioned in the chapter 6, the expected input of the Information Manager, related to the
operation of the system is 132 days. The input required for the document management may
decrease as the re-designed information system will be able to automate some of the tasks.
UNDP/GEF DANUBE REGIONAL PROJECT
Restructuring of the ICPDR Information System
page 28
8. CONCLUSIONS
The following steps will be needed to do the reconstruction of the system:
>
Decision on the changes in the content of the system (if any!), in terms of databases
and planned applications
>
Restructuring of the main content navigation menu (at least partly)
>
Selection of the system architecture
>
Implementation of the system
The input needed for reconstruction of the main content navigation menu will depend on
complexity of the content and also if uploading of additional information will be included. It may
vary from 1 to 3 weeks.
Input required for the system implementation will be 8 12 weeks of work of a specialised expert,
depending on the system architecture solution.
For the system operation, the expected general input would be (12 +28) days/year for system
administration and development and 132 days for information management.
The calculation of costs should be based on expert rates used in Austria or rates used at the ICPDR
Secretariat.
UNDP/GEF DANUBE REGIONAL PROJECT