Information sharing across multiple humanitarian ......2 Information sharing between humanitarian organizations To have a better understanding of problems related to information exchange

Inf Technol Manage (2006) 7:277–291DOI 10.1007/s10799-006-0277-7

Information sharing across multiple humanitarianorganizations—a web-based information exchange platformfor project reportingStefan Huesemann

C© Springer Science + Business Media, LLC 2006

Abstract This article analyzes information sharingproblems in the humanitarian development sector andproposes the concept of a web-based exchange plat-form to face some of the technical challenges. The“Development Information Exchange System” is amediator-wrapper-architecture that uses XML docu-ments to loosely couple autonomous and heteroge-neous information systems. Detailed project infor-mation of humanitarian organizations that resides ondata provider systems can be formatted with XSLstylesheets according to the needs of the users andshared within or between organizations. The systemcan help to close the control loop by providing qual-itative information about humanitarian projects. Thismakes project management more efficient. The pro-posed architecture solves an interface problem betweenthe various partners and stakeholders of humanitarianprojects. It is a first step towards a service-orientedarchitecture between humanitarian organizations. Thenext step could be the definition of cross-organizationalbusiness processes. These processes may be definedplatform-independently with the Business Process Ex-ecution Language for Web Services. A prototype ofthe exchange platform is presented and evaluated inthis article.

S. Huesemann (�)Innovation Process Technology, University of Fribourg,Fenetta 13, 1752 Villars-sur-Glane, Switzerlande-mail: [email protected]

Keywords Loosely coupled information systems .

XML-based project reporting . Developmentinformation exchange system . Humanitarianorganization

1 Introduction

“Sharing information on their activities is oneway in which agencies can save money and time,by avoiding duplication of efforts achieved else-where, and helping them to find partners withwhom they can pool funds and expertise.” [1]

Information sharing and exchange problems thatwill be addressed in this article occur in various typesof companies and organizations. Special attention willbe given to organizations in the humanitarian develop-ment sector to illustrate the challenges and to proposesolutions.

Many information sharing problems between andwithin institutions are organizational in nature. Thisis why we will first analyze challenges from a busi-ness perspective in Section 1 Information Sharing be-tween Humanitarian Organizations. Subject areas thatare pertinent are knowledge management [2, 3] and or-ganizational learning [4–6]. As these concepts are verygeneral we focus on specific problems related to projectmanagement in non-profit organizations.

There are technical challenges to data exchange be-tween systems. This vantage point will be taken in

Springer

278 Inf Technol Manage (2006) 7:277–291

Section 2 Information Exchange between Heteroge-neous Information Systems. Theory about integrationof heterogeneous and distributed systems will be con-sidered.

The research question we would like to answer is:What technical architecture can enable project stake-holders to share information across organizations?

In Section 3 Development Information ExchangeSystem (DIES) we will present a concept, the result-ing architecture and the prototype of a web-based in-formation system for cross-organizational informationexchange.

The concept of the “Development Information Ex-change System (DIES)” shows how information andcommunication technology can not only solve tech-nical problems, but also enable organizations to facesome business problems.

From a research paradigm point of view, the workcan be classified as design science. According to Marchand Smith [7] design science is concerned with devisingartifacts to attain goals, while natural science is con-cerned with explaining how and why things are. Designscience generates four types of output: Concepts, mod-els, methods and implementations. The main researchactivities are development of artifacts and their evalu-ation.

The research project was carried out according to theRational Unified Process [8]. This project managementmethodology is specialized on software development.

Strengths, weaknesses, opportunities and threats ofthe artifact are evaluated in Section 4 Evaluation of theDIES. The last section will put the presented solutionin a wider context and look into the future.

2 Information sharing between humanitarianorganizations

To have a better understanding of problems related toinformation exchange in development projects we firstdescribe the context.

2.1 Humanitarian development organizations

Almost anywhere in the world there are people whoneed substantial help to survive and to live on a min-imal standard [9–11]. That is the reason why human-itarian organizations (like the Red Cross) exist. Hu-manitarian organizations are often non-governmental

organizations (NGOs) that organize programmes andprojects in two major fields [12]:� Relief activities, i.e. short term interventions such as

refugee support in crises and� development projects, i.e. medium or long term ac-tions with sustainable impact such as education offarmers or the construction of infrastructure.

The term “development project” is also used in theinformation technology (IT) sector. If relating to ITprojects we will use the expression “software develop-ment”. The terms “humanitarian project / organization”and “development project / organization” will be usedas synonyms in this article.

International funding agencies and private donorsgive financial support to humanitarian organizations.There is increasing competition for donations betweenorganizations. Although many NGOs have similar ob-jectives, the fight for financial resources discouragesthem from cooperating. On the other hand, many part-ners can be involved in a project. In general, one or morefunding agencies (e.g. ECHO for Europe [13], USAIDfor the USA) and many private donors give money orother resources to international humanitarian organiza-tions. They set up programmes which can be composedof several projects (e.g. World Health Organization pro-gramme for the eradication of malaria). In cooperationwith local partners specific projects are defined andresources are allocated. Local partners can be compa-nies, governments or non-governmental organizations.Sometimes the local partners contract other partners toachieve their goals. The main objective of humanitarianprojects is to help needy people [9, 11, 14].

2.2 The broken control loop

The analysis of the situation in the inception phase ofthe research project has led us to formulate the follow-ing hypothesis: Within the humanitarian developmentsector there is little allocation of resources by marketmechanisms (supply and demand). It is also difficult toconceive an allocation based on financial results, be-cause such measures are not applicable or not available(how should the construction of a well or the educationof a child in Asia be evaluated?) [15, 16].

Profit-oriented companies have the generation ofprofits as their main objective. They can use profit-ratios as feedback for the work they have done (e.g.earnings per share (EPS), earnings before interests and

Springer

Inf Technol Manage (2006) 7:277–291 279

Funding agencies / private donors Humanitarian

organizationsproduction of output

Client

Supplier

Donations / funds / subventions

Input (goods, services)

Output (goods, services) e.g. humanitarian aid

Sometimes symbolic paymentInformation about activities

Reinvestment of potential surplus

Fig. 1 Interrupted control loop in humanitarian organizations

taxes (EBIT) [17]). Based on the results of precedingperiods in combination with strategic considerations,the resource allocation is determined for the follow-ing period. This cycle is called control or feedbackloop [18].

Humanitarian organizations do not aim to earn prof-its, and there is almost no cash flow out of the projectsback to the NGOs. Thus, the financial ratios which arenormally used in profit-oriented companies cannot beapplied fully to NGOs. The main objectives refer toissues such as the improvement of training conditionsin countries in transition or the eradication of a spe-cific disease [14, 19]. These kinds of objectives arevery difficult to measure and correlation of the impactswith the invested funds is hard to prove (e.g. fightingagainst drug abuse, elimination of diseases, improve-ment of the overall economic situation of a country,providing humanitarian relief to refugees).

There is almost no allocation of resources whichcould be guided by profit-ratios. The decision-makingprocess can be influenced by the donors in a limitedway, above all by institutional funding agencies. Oneprecondition, however, is that the donors are well in-formed about the projects and their impacts. Contraryto private donors, governments and funding agencieswant to be informed in great detail to know what hashappened to their funds, and they have the power toenforce these requirements.

Figure 1 illustrates resources flow in developmentprojects. Two potential deficiencies in the control loopof an internationally working humanitarian organiza-tion have been identified:� On the one hand the information feedback from

field projects to humanitarian organizations—whichcan be an information flow within the sameorganization—is often insufficient (dotted line on theright side of Fig. 1).� On the other hand the information flow from hu-manitarian organizations to donors which is cross-organizational information flow is weak (dotted lineon the left side of Fig. 1).

These deficiencies of the system are our startingpoint for improving the allocation of available re-sources and the management of humanitarian projects.

2.3 Characteristics of development projects

Development projects are medium to long term. Theprojects have many stakeholders as described above.The stakeholders are paying attention to the well-goingof the project. They are interested in sharing informa-tion to avoid repeating errors and foster organizationallearning. Information about projects may be stored inmany different information systems and project man-agement systems.

Springer


Stakeholders of a project communicate through var-ious channels. Every group is interested in specificfacets of information about projects [20]. Increasingamounts of information are exchanged electronically.Many organizations publish facts about their past, on-going or planned projects on the Internet now.

More detailed information like project reports areexchanged directly between project participants. How-ever, there is little standardized electronic data ex-change between the stakeholders. There is no commonstandard for the exchange of project information andmore detailed reports. This issue will be consideredlater. For an analysis of websites that publish informa-tion on development projects see [21].

Although interested people can find certain informa-tion on websites of organizations it is still difficult toget an overview of what is undertaken by different inde-pendent groups, e.g. in a region. “The effectiveness offoreign aid is impaired by deficient information, frag-mentation, and lack of coordination.” [22]

After these general considerations we would like tolook more closely at benefits of information sharingacross organizations as well as to related problems andbarriers.

2.4 Benefits of information sharing acrossorganizations: Closing the broken control loop

To close the broken control loop, humanitarian orga-nizations have to invest some of the money they getand a lot of time in reporting and evaluations [6, 16].They see this often as an administrative burden withno value added. The reporting system is first and fore-most an instrument for controlling. But depending onthe report, valuable information can be found for fu-ture and ongoing projects. Therefore one should con-sider whether and in what form such project reportsand evaluations could be made available. The manage-ment of humanitarian projects can be improved by thedocumentation (explicit knowledge) and handing overof experience (implicit knowledge) [23, 24]. These as-pects have been treated in the field of knowledge man-agement. Creech and Willard [25] discuss how sustain-able development can be achieved by using knowledgemanagement concepts.

The donors must be informed about the activities ofthe humanitarian organizations, in order that they cancontrol what happens to funds made available. In casethe results achieved are evaluated as positive, the donors

will hopefully increase their proximate funding, whichmeans a more effective distribution of funds from out-side of the humanitarian organizations.

To keep administrative costs for reporting as low aspossible while having the required information avail-able, reports could be composed of various reportingcomponents or modules. These modules could subse-quently be joined according to the information needsof the recipient. A platform for the exchange of stan-dardized information used by all stakeholders for com-munication would be very helpful in this respect.

Contrary to physical goods, the value of informationrises if it is shared [25]. This idea is the basis for mostbenefits of knowledge sharing discussed in theory andpractice.

2.5 Problems and barriers to information sharing

Although the benefits of information sharing may bequite obvious, information is often not exchangedfreely, even in a non-profit environment where finan-cial objectives are not at the top of the goal hier-archy. Various barriers can be determined that pre-vent organizations or individuals to share information.Some of the problems are categorized here in threefields:� Organizational problems,� cultural problems and� technical problems.

Organizational Problems relate to the specific natureof non-profit organizations and humanitarian projects.Some of these problems are:� Coordination of projects / transparency:

There is a great number of non-profit organizationsrespectively NGOs working in the field of human-itarian projects. Obviously it is very difficult (andnot absolutely necessary) for these organizations tobe fully informed about all development projectswhich are planned or carried out by other human-itarian organizations. On the other hand experiencehas shown that uncoordinated help within a regioncan be highly counter-productive, even if the orga-nizations have similar objectives [10]. It is also afact that problems of coordination are omnipresenteven within humanitarian organizations, whichare usually structured in a federal, decentralizedway.

Springer

Inf Technol Manage (2006) 7:277–291 281� Geographical distance:Development projects are international. Organiza-tions from different countries cooperate. The dis-tance between the stakeholders makes coordinationand information sharing more difficult.� Decisions are influenced by politics:A great percentage of the funds that humanitarianorganizations need to carry out projects come fromgovernmental funding agencies. They usually pur-sue political objectives and influence the decisionmaking process in development organizations. In-formation about needs of people and effectiveness ofprojects is sometimes neglected in this context.� Competition between organizations:Several organizations work in similar fields and com-pete for the same resources (donations, credits etc.).They do not want to share information although theymay have the same objectives, i.e. help needy people.� Confidentiality of certain information:Not all information is suited for sharing, e.g. pub-lished information about projects in totalitarian coun-tries may endanger the participants.� Lack of motivation for information sharing:Information sharing needs a big effort of the stake-holders. They have to see the benefits of sharing fortheir organization and for themselves.

Cultural Problems relate to people and their customs:� Variety of stakeholders and of information exchange:As seen above, stakeholders are located in variouscountries. They speak various languages, have dif-ferent education levels and diverse cultural back-grounds. This makes communication and coordi-nation within and between development projectsdifficult.� Information is power:Information is often used to control the power—bynot sharing information, a person or institution maymaintain its competitive advantages and influence.

Technical Problems can relate to infrastructure andinformation systems:� Infrastructure:

Lack of telecommunication and IT infrastructure indeveloping countries is a challenge for worldwideinformation exchange. Employees or volunteers canonly communicate under difficult circumstances withtheir headquarters.

� Differing requirements of institutional donors forproject reporting / costs of information exchange:Although project reports and evaluations mostly con-tain similar information, every organization has itsown structure and format. This is a challenge for in-formation exchange.Reporting within humanitarian organizations and es-pecially between them and institutional donors iscostly and time-consuming, because every institu-tion wants customized information.� Heterogeneous information systems:Information has to be put in a format that can beexchanged electronically between information sys-tems. The lack of information exchange standardsin the humanitarian field and especially for projectreporting and evaluation is a barrier to informationexchange across organizations.� Accessibility of information:A lot of information is not used because it is notavailable to potential users at the right time the rightplace and the right format.

The order of the problems and barriers has been cho-sen deliberately. It is not an exhaustive List of problems.Organizational and cultural barriers are much more dif-ficult and time-consuming to overcome. It takes a lotof effort to change habits and prejudices. Denning [2]states that knowledge management in the World Bankis 80% brainpower and 20% information technology.

On the other hand, technical problems can inhibit in-formation exchange altogether. Information and com-munication technology is the enabler for informationexchange across organizations.

This is why we will focus on proposing a technicalsolution for information sharing in the humanitarianfield. The concept will take into consideration organi-zational and cultural aspects, although there is no tech-nical solution for many of them. The concept shouldaddress the problems related to reporting to multiplepartners, simplify reporting between humanitarian or-ganizations and institutional donors and make experi-ence from past projects available.

3 Information exchange between heterogeneousinformation systems

Three problem areas have been outlined in the previ-ous chapter. Now, we will present ways of approachingtechnical problems related to information exchange.

Springer


We will first discuss architectures that enable informa-tion exchange between information systems of differ-ent organizations. Then, information systems used inhumanitarian organizations are classified.

Information can mostly be stored and exchangedelectronically. The systems involved in exchanges canbe very heterogeneous (i.e. they run on different oper-ating systems, on different types of computers, they arebased on different data models, they are programmedin different languages). To enable them to communi-cate with each other integration concepts have beenproposed. Some integration architectures are discussednow. We only consider Extensible Markup Language(XML) as data transport format although some of thearchitectural options have also been realized with otherformats like UN-EDIFACT [26].

3.1 Architectures to integrate heterogeneousinformation systems

Information systems (IS) can build on a variety of datamodels (e.g. hierarchical, relational, object-oriented,XML). Raghavan and Garcia-Molina [27] classifiedexisting architectures for tying different IS into threecategories:� Layered architectures,� loosely coupled architectures and� extension architectures.

In systems with a layered architecture, an IS ofone type is implemented as an application that oper-ates over an IS of another type. The main advantageof this approach is that the top-level system can lever-age the facilities of the underlying one, without sig-nificant additional development time and effort. How-ever, the challenge lies in mapping the data types andoperators used by the top-level system in terms ofthe types and operators supported by the underlyingIS [27].

Loosely coupled architectures isolate the integra-tion logic in a separate integration (or mediation) layer.This layer provides a unified access interface to theintegrated system using its own data and query lan-guages. The fundamental challenge in this architectureis to design efficient mechanisms to translate queriesexpressed in the unified model in terms of the querycapabilities of the individual IS. The advantage is thatunlike the layered and extension architectures, modifi-cations to the individual IS are minimal or completely

unnecessary. This approach is also known as mediator-wrapper-architecture [28–30].

Finally, extension architectures enhance the capa-bilities of a particular type of IS by using an extensionmodule that provides support for new data types, op-erators, or query languages usually available only inthe IS of another type. When extension interfaces areavailable in the original IS the extension module canbe implemented using these interfaces.

The more autonomous the systems and the more het-erogeneous the data to be integrated are, the more dif-ficult it is to implement a tightly coupled architecture[31]. Loosely coupled architectures give less function-ality, but they do not require having full control overthe systems that exchange information. The underly-ing systems can change without having to change thewhole distributed system.

A major problem when integrating information fromheterogeneous systems is the mapping of the involveddata models or schemas [32]. There are tools that canhelp with this task, but human interaction is necessaryto resolve ambiguities.

A vision for information exchange between looselycoupled systems is the service-oriented architecture(SOA). “In essence, SOA is a way of designing a soft-ware system to provide services to either end-user ap-plications or other services through published and dis-coverable interfaces.” [33]

The idea to use services, which are coarse-grainedsoftware entities that use a message-based communica-tion model, has been around for some years. SOAs havemainly been implemented within companies. With therise of Web Services (WS) [34] and related standardslike WS-Security [35] and Business Process Execu-tion Language for Web Services (BPEL4WS) the SOAvision begins to be feasible for cross-organizationalinformation exchange [36]. Business Process Execu-tion Language for Web Services [37] allows organizingmultiple WS to a cross organizational business process.The information flow can be modeled in a flexible andplatform-independent way.

Another option for data integration is the data ware-house approach [38, 39]. In this type of architecturedata from different systems are extracted, transformedand finally loaded (ETL-process) into a centralizeddatabase. This data warehouse can be queried by on-line analytical processing (OLAP) tools that providedrilling functionalities. Quantitative data can be ana-lyzed with great flexibility.

Springer


DIES

Project Monitoring System Project Monitoring SystemDonor / funding agency

Internationalhumanitarianorganization

Independent organization

Project ManagementSystem


Project A Project B Project 1Project C Project 2

Organization Information System

Financial focus,planning, monitoring

Operative System,planning, implementingmonitoring, controlling

Reporting focus,information exchange, coordination

Main Focus/ Functionality

DIES

Project Monitoring System Project Monitoring SystemDonor / funding agency

Internationalhumanitarianorganization

Independent organization



Project A Project B Project 1Project C Project 2

Organization Information System

Financial focus,planning, monitoring

Operative System,planning, implementingmonitoring, controlling

Reporting focus,information exchange, coordination

Main Focus/ Functionality

Fig. 2 DIES as interface between different information systems

The difference between the data warehouse ap-proach and the tree approaches described before is, thatdata is duplicated and stored centrally.

Data warehouses are not useful for the stor-age of qualitative information like project reportsin humanitarian organizations. This makes themunsuitable for the context of information sharingbetween humanitarian organizations described inSection 1.

A loosely coupled mediator-wrapper-architecturewas chosen to implement the Development Informa-tion Exchange System (DIES). This kind of archi-tecture has the advantage that underlying systems donot have to be modified and that it is easy to add newsystems to the exchange platform. It is a suited archi-tecture to integrate heterogeneous information systems(cf. 1.5 Problems and barriers to Information Sharing)[29].

The DIES will represent a mediator which gives anabstract, integrated view on the data stored in the dataprovider systems. The mediator can be implementedas one or several services which can be used by othersystems. The mediator will also have a graphical userinterface for direct use by human users through theWorld Wide Web (WWW). For a mediator to work therehas to be a common exchange standard. This standardwill be XML. The schemas used to define the structureof the XML will be described in chapter 3.2 Proof ofConcept of the DIES.

3.2 Types of information systems in humanitarianorganizations

Stakeholders that are interested in information ex-change usually store and manage their data in own in-formation systems [40]. Depending on their focus thesesystems can be classified. We can find project manage-ment systems with an operational focus, monitoringsystems with a financial focus or organizational mem-ory information systems with a focus on knowledgemanagement and organizational learning.

Figure 2 shows different types of information sys-tems, organizations that typically use them and the mainfocus of the systems. It shows how a DIES could act asmediator to integrate these systems.

The DIES can be used on different organizationallevels: Between organizations (as shown in Figure 2)or within international organizations with a federativestructure for the integration of their own heterogeneoussystems.

4 Development information exchange system(DIES)

Now that the situation has been described and someof the problems have been analyzed, a more detailedsolution can be conceived. The state of the art will haveto be taken into consideration. Detailed system require-ments and specifications are not included in this paper.

Springer


Standardizedinfo-exchange

Stakeholder

Development Information Exchange

Platform

Exchange of general projectinformation, project reports

and evaluations

Marketplace for projectexperiences

Donors / funding agencies

DEZA ECHO Others ...

International humanitarianorganizations

Others ...

Caritas

Red Cross

Local partners,suppliers

NGOs

companies

governments

Recipients

Countries,regions

Persons,groups

Companies, others ...

P-reports

P-infos

P-proposals

P- reports

P-infos

P-proposals

Communication,partner search,find resources,public relations

Communication,partner search,

who is doing what?find resources,

monitoring

Report crises /Analyze needs

Report crises /Analyze needs

Needs of recipients

P-proposalsP-infos

P- reports

Communication, partner search,

resource allocation,needs analysis,

project coordination,monitoring

Fig. 3 Information exchange with the DIES

4.1 Vision and objectives of the DIES

The vision of the DIES is to help close the brokencontrol loop. Its objectives are to enable organizationallearning, enhance information sharing within and be-tween organizations and to minimize administrativeburden in the field of project reporting.

Scenarios and use cases [8, 41] have been defined todetermine the requirements for the Development Infor-mation Exchange System. One use case is called “Re-porting of an international humanitarian organization toseveral donors”. In this use case an organization imple-ments a development project which is supported by sev-eral funding agencies. All agencies require informationabout the progress of the project and the usage of theirfunds. The humanitarian organization produces com-prehensive internal project reports, which are stored inits project information system. Content and format areseparated in its database. The comprehensive reportsare registered in the DIES by the data owner. Whena donor of the project gets the report through the ex-change platform the DIES transforms and formats thedata according to the requirements of the user.

From this and other use cases not described here,we can deduce some of the system requirements: Thefocus is on the exchange of project reports and evalua-tions. The DIES should enable platform-independent

information exchange. Systems of data providersshould not have to be modified. Data should not beduplicated on the DIES, i.e. data stays on the sourcesystems. In this way, the data provider systems stayautonomous. Another requirement is the separation ofcontent and format of the documents to be exchanged.

Figure 3 shows the vision of a computer-based infor-mation system which could be used as a standardizedplatform for the exchange of project information andfor the coordination of projects. Such a system wouldbe set up independently of the NGOs and funding agen-cies.

In the boxes we find stakeholders described in pre-vious sections. The clouds show possible uses of thesystem by the stakeholders. The broad arrows repre-sent the standardized exchange of information throughthe DIES which is symbolized by a circle in the middle.

How the exchange works in detail will be explainedin the next chapter, where we will show the prototypethat was built to demonstrate the feasibility of the DIESconcept.

4.2 Proof of concept of the DIES

This chapter describes three parts of the DIES artifact:The exchange standard, the architecture and the webapplication.

Springer


4.2.1 Information exchange standard: IdmlReporting

To easily collect data from different IS it is necessary tohave an exchange standard that fulfills the informationneeds of the stakeholders of development projects. Theemerging standard for this type of information is the In-ternational Development Markup Language (IDML).Various organizations already use IDML for sharingsimple project information, among them the Devel-opment Gateway, the World Bank, OECD and UNDP[42, 43].

IDML as exchange standard is an XML-based setof tags and rules for the types of information that areunique to the development sector. Elements of the coreactivity schema include project titles, organizations thatare involved and their roles, persons involved and fund-ing details. Some of these elements can be found inany type of project. Others like “funding” or “orga-nizations involved” are more specific to internationaldevelopment projects. Funding can come from variousdonors, and several organizations can be involved. The

content of the elements and attributes is probably thebiggest difference between humanitarian projects andprofit-oriented projects [44].

IDML is designed to give a high level description ofactivities in the development sector. It is not suited toexchange detailed project reports and evaluations. Thisis why a new exchange standard based on IDML wasproposed by the author.

The schema was called idmlReporting. It is imple-mented as XML Schema [45]. Special attention wasgiven to the reusability of certain parts of the schemaby using complex types. The schema is divided intofour parts:� Detailed description,� reporting,� evaluation and� financial information.

Figure 4 shows the structure of idmlReporting. Thediagram shows the main elements of an idmlReport-ing Document. The child elements of “reportNumber”,

Fig. 4 Tree view of the idmlReporting schema

Springer


“detailedDescription”, “reporting”, “evaluation” and“financialInformation” are hidden (+ sign in Figure 4).

An idmlReporting document is composed of a rootelement “reportsAndEvaluations”, which can containan unlimited number of “reportAndEvaluation” ele-ments. The element “reportAndEvaluation” is definedas complex type “reportType” (broken frame in Fig. 4).The “reportType” contains the four above-mentionedmain parts as well as metadata on the report (number,name, date, description). The dotted line between theelements tells us that they are optional.

An idmlReporting document can contain several re-ports and evaluations. It is possible to keep all informa-tion on one project together (e.g. project proposal, pe-riodic project reports, an intermediate and a final evalu-ation) in one XML document. More information aboutidmlReporting as well as the full XML schema can befound in [46].

4.2.2 Architecture of the development informationexchange system

The DIES is a mediator through which semi-structuredinformation that resides on autonomous IS can be ac-cessed. The mediator communicates with wrapperswhich are built around the data provider systems. Thesewrappers enable the underlying IS to receive requestsfrom the DIES and to generate IDML and idmlReport-ing documents. How such a wrapper can be built isdiscussed in [29, 44].

Figure 5 describes the architecture of the DIES andthe process of information exchange through the sys-tem [47]. In the rectangles we see the systems of the

data requestors and providers. The DIES is composedof a web server, a database with administrative infor-mation and an optional set of standard XSLT and XSL-FO stylesheets [48]. The arrows represent informationflow.

1. A person or information system identifies itself onthe DIES web server.

2. The system authenticates the user and grants himaccess rights that are specified in the DIES database.The user selects a document from the list of availablereports.

3. The DIES calls the data provider system via WWW.4. The data provider sends back the requested XML

document. An XML generator can be used to pro-duce the document on-the-fly. This generator acts asa wrapper around the information system.

5. The XML document is transformed and formatteddepending on the user rights and the XSL stylesheetchosen. The stylesheet itself can be loaded from adata provider as well.

6. The resulting document is sent to the client.7. It can be used as is or processed and imported

into the systems of the requestor in an automatedmanner.

This architecture allows integrating any number ofdata provider systems in a loosely coupled way. Precon-dition for the connection of the system of a developmentorganization is its ability to provide XML documents.These documents should follow the IDML and idml-Reporting schemas which are the preferred exchangestandards and used as a common language for commu-nication in the DIES.

Fig. 5 Architecture of thedevelopment informationexchange system

Springer


The architecture fulfills the basic requirements de-termined for an information exchange platform for hu-manitarian organizations. It has the advantage that in-formation is entered, stored, and updated on data own-ers’ systems. The reporting organizations keep full con-trol over their data, which may help to avoid the “po-litical” problems of implementation.

4.2.3 Web-based information exchange platform(DIES web application)

The DIES web application runs on a web server andcontains the business logic. It builds on the DIESdatabase and defines what happens with the data.The application is implemented with Microsoft ActiveServer Pages [49]. The loading and manipulation ofXML documents and XSL stylesheets is done via Doc-ument Object Model (DOM) [50].

The DIES web application enables authorized usersto select project reports and to choose an output for-mat. The documents are in XML format. The pre-ferred schemas are IDML and idmlReporting, but anyother exchange standard can be used. The transforma-tion and formatting of the documents is done via XSLstylesheets.

The XML as well as the XSL can originate fromany connected information system and is loaded bythe DIES on-the-fly. Only the metadata about the doc-uments and some administrative data is stored in theDIES database (Unique Resource Locators (URL), ac-cess rights of users, source system, etc.).

The main menu of the DIES member website hasthree sections:� Development Information Exchange System which

groups the central functions of the system like viewproject information or register new XML documentsand XSL stylesheets.� Members which gives access to the list of DIES mem-bers and the administration of personal profiles.� Puclic Domain where non-confidential informationcan be accessed without being authenticated.

If a user wants to get information on a specificproject e.g. of a partner organization he can navigateto the “Display Project Information” page shown inFig. 6. Depending on the user rights he gets a list ofdocuments that are accessible. Any of these documentscan be formatted with one of the stylesheets availablein the drop-down list. The stylesheets can be used togive only access to certain elements of a document.

Fig. 6 DIES web application—selection of document and stylesheet

Springer


In Fig. 6 the user selected the XML document “AirQuality Project Bangkok (idmlReporting)” and the listof available XSL stylesheets is still open.

Once the button “See document with stylesheet” ispushed the selected document is loaded from the URLregistered in the DIES database. It does not matter ifthe document is stored locally or on another web serveras long as the DIES has the proper access rights to themachine. Then the stylesheet is loaded and applied tothe document. The result is a new document that is sentto the requestor.

All transformations are executed on the DIES webserver. This ensures the platform independence of theoutput. It is important to note from a security point ofview that the clients do not connect directly to the dataprovider systems.

The output can directly be displayed in the DIES.Depending on the stylesheet the result will be HTML orXML. A report in XML format can be chosen, if furtherprocessing and automated importing into informationsystems of the client is needed.

In this chapter we have seen the graphical user in-terface of the DIES. But the exchange platform canalso be used by systems. In this case the DIES acts asa Web Service. A SOAP message [34] is sent to theDIES with information about the user, the data neededand the output format. The DIES retrieves the infor-mation form the sources and transforms it. The docu-ment is sent back to the data requestor within a SOAPenvelope. The recipient can then further process theinformation.

5 Evaluation of the DIES

So far, we analyzed specific information exchangeproblems, proposed a concept to solve them and builta prototype as proof of concept. In terms of the de-sign science paradigm we have an artifact now. Animportant part of the chosen methodology is the eval-uation of this artifact. The evaluation should show ifthe proposed solution leads to any improvement of thesituation.

A strengths weaknesses opportunities threats(SWOT) analysis of the architecture, the idmlReportingexchange standard as well as the DIES prototype wascarried out. The SWOT analysis is a method often usedin strategic analysis [51] or marketing [52]. Strengthsand weaknesses relate to the artifact and the organi-

zation using it, opportunities and threats tell us aboutthe future and relate to the environment of the DIES.Various evaluation criteria proposed in the informationsystem literature [53] have been used to rate the arti-fact. The requirements that were set up based on theproblem description were also used to see whether thesystem may be useful.

5.1 Fulfillment of requirements

The DIES fulfills both the functional and non-functional requirements for an information exchangeplatform in the humanitarian development sector to agreat extent [15]. It can be run by an independent or-ganization and it is accessible from anywhere via theWWW. Confidential information can be made accessi-ble to authorized users while the costs for administer-ing the platform are low because most tasks are man-aged by the users. General as well as specific projectinformation like reports and evaluations can be ex-changed in human and machine readable format thanksto XML and the idmlReporting schema. Informationthat is stored on project information systems of dif-ferent organizations can be made accessible throughthe DIES. The information is updated and managed bythe information owners, i.e. the humanitarian organi-zations or funding agencies. They are responsible forgranting access rights to information as well as keepingdata up-to-date.

5.2 Strengths and weaknesses

From a technical point of view it is important topoint out the capability of the DIES to couple au-tonomous information systems. These systems do notneed to be adapted; they only need an XML gener-ator as wrapper. The DIES represents the mediatorin the mediator-wrapper-architecture (cf. chapter 2.1Architectures to Integrate Heterogeneous InformationSystems).

A strength of the architecture is that data is directlyupdated in the systems of the data providers. The plat-form allows the users to access up-to-date information.The DIES does not duplicate the data (non-persistentdata); it loads data whenever a user wants to see a spe-cific report.

A weakness of the concept is that documents that areto be exchanged have to be in XML format. Low-techorganizations may have difficulties to do this.

Springer


Furthermore, information that does not fit into theelements of the IDML or idmlReporting schemas maynot be exchanged easily. In this case the schemas wouldhave to be extended. The problem with extending orchanging the exchange format is that all data providershave to adapt the mapping between their informationsystem and the schema to ensure that the wrapper stillgenerates valid documents. The data requestors mayalso have to modify their XML processor for the im-port of the documents. Alternatively, different versionsof the same schema could be used in parallel in theDIES. The exchange platform itself does not have tobe modified when the exchange standard changes.

Another weakness may be the management of theaccess rights. Data owners can define access rights totheir documents on the DIES web application. It is alsopossible to grant access to specific parts of the docu-ment by providing certain users only with stylesheetsthat filter some elements. However, if the user has ac-cess to various stylesheets on the DIES, it is difficult toavoid that one of these permits him to see confidentialelements.

The performance of the system is the last weak pointmentioned here. Documents have to be loaded fromtheir original source. The size of these documents canbe big compared to traditional web pages or word doc-uments, since XML is used as exchange format.

However, the advantage of the XML tags is that atext may be searched, transformed or formatted seam-lessly. Documents in IDML or idmlReporting formatare structured and can be validated against the schemas.Well structured and standardized reports are easier toread and to understand. The structure is flexible sincemost elements are optional. The schemas are extensibleand complex types can be reused in other schemas.

5.3 Opportunities and threats

Some of the threats associated with the introductionof the DIES are related to the standardization of in-formation exchange. A predefined exchange standardcan limit the richness of reports or evaluations. Further-more, it is possible that users do not like to be constraintto a predefined structure of their reports.

Another threat is that project participants mightoverestimate the possibilities of IT. For instance, theyshould not get the impression that the content of projectevaluations will be generated automatically in the fu-ture.

An exchange platform that makes transparent certaininformation on projects can lead to changing motiva-tions of project stakeholders. To ensure the success ofinformation sharing it is crucial to give the stakehold-ers incentives to cooperate. Ballantine et al. [54] give agood insight into this subject, which will not be treatedin more detail here.

The opportunities for organizations to use a DIESconcept are by far outnumbering the threats. As men-tioned before, information sharing between stakehold-ers of development projects gives the opportunity tolearn from past projects. It also improves the abilitiesto coordinate planned and running projects of variousorganizations. Sharing of information can also lead tocollaboration opportunities with new partners.

The automation of parts of the information exchangeprocess is another opportunity. It lowers the adminis-trative costs and saves time—time that can be used tobetter fulfill the core activities of humanitarian projects.

6 Conclusions and outlook

This article gave an overview of information shar-ing problems that occur in humanitarian developmentprojects. Some problems can be addressed by a web-based exchange platform. The DIES concept is onepossible answer to the question, what technical archi-tecture could enable project stakeholders to share infor-mation across organizations. The DIES can be seen asa technical enabler for information exchange. But otherbarriers like cultural and organizational differences be-tween organizations and people have to be addressed tosucceed in the organizational learning effort. The stake-holders must be motivated and see a sense in using theDIES (“carpe DIEM”).

The following conclusions can be drawn from thework that has been presented:� The DIES can help to close the control loop. This

makes project management more efficient.� The proposed architecture solves an interface prob-lem between the various partners and stakeholders ofhumanitarian projects.

The usage of the DIES can be seen as a first step to-wards a service-oriented architecture between human-itarian organizations. The next step could be the defini-tion of cross-organizational business processes. Theseprocesses may be defined platform-independently with

Springer


the Business Process Execution Language for Web Ser-vices. The DIES Web Service could then seamlesslybe integrated in the information flow and deliver doc-uments that are routed to the next service or person inthe business process.

Coordination of projects is very important to avoidinefficiencies. However, this coordination should notbe done centrally. Democratic decision-making and de-centralization are very important for NGOs. The DIESdoes not coordinate, but makes information availableto enable the stakeholders to coordinate their activities.Therefore it promotes decentralized and well fundeddecision-making. The DIES may be one building blockfor improving the impact of development projects andmay help humanitarian organizations to optimize theallocation of their limited resources.

References

1. INDIX. International Network for Development Informa-tion Exchange. International Network for Development In-formation Exchange (INDIX) (2000), http://www.indix.org(discontinued, Development Gateway has taken over someINDIX activities) (accessed 2000-01-04).

2. S. Denning, in: The Knowledge Perspective, R. Ruggles andD. Holtshouse, (eds.) The Knowledge Advantage, Oxford:Capstone Publishing Ltd. (1999) pp. 143–161.

3. I. Nonaka and H. Takeuchi, The Knowledge Creating Com-pany (1995) Oxford: Oxford University Press.

4. P.M. Senge, The Fifth Discipline: The Art and Practice of TheLearning Organization, New York, NY: Doubleday (1990).

5. J.V. Vanderville, Organizational Learning Through the Col-lection of “Lessons Learned”. Informing Science, 3(3)(2000) 127–133.

6. M. Estrella (ed.), Learning from Change—Issues and Experi-ences in Participatory Monitoring and Evaluation. London:Intermediate Technology Publications Ltd. (2000).

7. S.T. March and G.F. Smith, Design and natural science re-search on information technology, Decision Support Sys-tems 15 (1995) 251–266.

8. Rational. Rational Unified Process for Software EngineeringRUP SE 1.0. USA (2001).

9. UN. Millennium Development Goals. United Nations (2000),http://www.developmentgoals.org (accessed 2003-08-29).

10. J. Eriksson, The Drive to Partnership: Aid Coordination andthe World Bank. Report, Washington (DC), USA: WorldBank, Operations Evaluation Department (OED) (2001).

11. IFRC. World Disasters Report 2000. Yearly Report, Geneva,Switzerland: International Federation of Red Cross and RedCrescent Societies (2000).

12. IFRC. Description of the International Federation of RedCross and Red Crescent Societies. International Federationof Red Cross and Red Crescent Societies (2002), http://www.ifrc.org/who (accessed 2003-05-05).

13. ECHO. ECHO—Humanitarian Aid Office. European Com-mission Humanitarian Office (ECHO) (2002), http://europa.eu.int/comm/echo (accessed 2003-04-29).

14. P. Schwarz, R. Purtschert and C. Giroud, Das FreiburgerManagement-Modell fur Nonprofit-Organisationen. 3. Au-flage. Bern: Haupt Verlag (1999).

15. S. Huesemann, Web-basierte Informationsaustauschplat-tform fur Internationale Humanitare Projekte. DUVWirtschaftsinformatik. Wiesbaden: Deutscher Universitats-Verlag DUV (2003).

16. K. Pasteur and J. Blauert, Participatory Monitoring andEvaluation in Latin America: Overview of the Literature withAnnotated Bibliography, Brighton, Sussex, England: Insti-tute for Development Studies (IDS), University of Sussex(2000).

17. R.A. Brealey and S.C. Myers, Principles of Corporate Fi-nance, 6th Edition. New York: McGraw-Hill (2000).

18. G. Probst and T. Dyllick, in: Kybernetische Fuhrungstheo-rien, Handworterbuch der Fuhrung, A. Kieser, G. Reber andR. Wunderer, (eds.) Stuttgart, Deutschland: Poeschel Verlag(1987) p. 823ff.

19. R. Schauer, et al. (eds.), Nonprofit-Organisationen imWandel: Herausforderungen, Gesellschaftliche Verantwor-tung, Perspektiven. Linz: Universitatsverlag Rudolf Trauner(2000).

20. S. Madon, International NGOs: networking, informationflows and learning, Journal of Strategic Information Systems8 (1999) 251–261.

21. S. Huesemann, Web-basierte Informationssysteme als Her-ausforderung. VM—Fachzeitschrift fur Verbandsund Non-profit-Management 2/2001 (2001) 34–41.

22. DG. Harnessing Knowledge and Technology for Sustain-able Development and Poverty Reduction. Project Proposal.Project Proposal, Washington (DC), USA: DevelopmentGateway (DG) (2000).

23. I. Nonaka, A dynamic theory of organizational knowledgecreation, Organization Science 5(1) (1994) 14–37.

24. I. Nonaka, P. Reinmoeller and D. Senoo, The ‘ART’ ofknowledge: systems to capitalize on market knowledge. Eu-ropean Management Journal 16(6) (1998) 673–684.

25. H. Creech and T. Willard, Strategic Intentions—ManagingKnowledge Networks for Sustainable Development. Win-nipeg, Canada: International Institute for Sustainable De-velopment (IISD) (2001).

26. UNECE. UN/EDIFACT—United Nations Directories forElectronic Data Interchange for Administration, Commerceand Transport. United Nations Economic Commissionfor Europe (UNECE) (2003), http://www.unece.org/trade/untdid/welcome.htm (accessed 2003-09-18).

27. S. Raghavan and H. Garcia-Molina, Integrating Diverse In-formation Management Systems: A Brief Survey. WorkingPaper, Stanford (CA), USA: Computer Science Department,Stanford University (2001).

28. Y. Papakonstantinou, A. Gupta and L. Haas, Capabilities—based Query Rewriting in Mediator Systems. Distributed andParallel Databases, Kluwer Academic Publishers (6) (1998)73–110.

29. P. Thiran and J.-L. Hainaut, Wrapper Development forLegacy Data Reuse. in Work Conference on Reengineering(WCRE). Stuttgart: IEEE (2001).

Springer


30. V. Josifovski and T. Risch, Query Decomposition for a Dis-tributed Object-Oriented Mediator System. Distributed andParallel Databases, Kluwer Academic Publishers, 11 (2002)307–336.

31. A. Bouguettaya, B. Benatallah and A. Elmagarmid, Inter-connecting Heterogeneous Information Systems. Distributedand Parallel Databases, Kluwer Academic Publishers (1998)p. XVI, 218 S.

32. S. Abiteboul, et al., Tools for data translation and integration.Bulletin of the Technical Committee on Data Engineering,IEEE Computer Society 22(1) (1999) 3–9.

33. Rational. Using Service-Oriented Architecture andComponent-Based Development to Build Web ServiceApplications. USA (2003) p. 15.

34. W3C/WebServices. Web Services. WWW Consortium(W3C) (2002), http://www.w3.org/2002/ws (accessed 2003-08-05).

35. C. Kaler, Web Service Security (WS-Security)—Version 1.0.Specification: IBM, Microsoft Inc., VeriSign (2002) p. 22.

36. M. Pezzini and Y. Natis, SOA Comes of Age via Web Services.Research Note: Gartner (2002) p. 6.

37. S. Thatte, et al. Business Process Execution Languagefor Web Services—Version 1.1. Specification: BEA Sys-tems, IBM, Microsoft Inc., SAP AG, Siebel Systems(2003).

38. W.H. Inmon, Building the Data Warehouse, 2nd Edition.New York (NY), USA: John Wiley & Sons (1996).

39. L. Silverston, W.H. Inmon and K. Graziano, The Data ModelResource Book : A Library of Logical Data Models and DataWarehouse Designs. New York: John Wiley & Sons (1997).

40. M. Powell, Information Management for Development Or-ganisations. Oxford, UK: Oxfam (1999).

41. J.A. Hoffer, J.F. George, and J.S. Valacich, Modern SystemsAnalysis and Design, 2nd Edition. Reading (MA), USA:Addison-Wesley Publishing Company (1999).

42. IDML. International Development Markup Language.IDML Initiative (2000), http://www.idmlinitiative.org (ac-cessed 2003-09-12).

43. DG. Homepage Development Gateway. Development Gate-way (DG) (2001), http://www.developmentgateway.org (ac-cessed 2003-09-06).

44. S. Huesemann, Information exchange between humanitarianorganizations: Using the XML Schema IDML, Journal of theAssociation for Information Systems (JAIS) 3 (2002) 1–26.

45. W3C/XMLSchema. Specification of XML Schema Standard.WWW Consortium (W3C) (2001), http://www.w3.org/XML/Schema (accessed 2003-08-12).

46. S. Huesemann, Homepage Dissertation Stefan Husemann(2002), http://www.huesemann.org/diss (accessed 2003-10-21).

47. S. Huesemann, in: Computergestutzter Informationsaus-tausch Zwischen Stakeholdern Humanitarer Projekte—dasDevelopment Information Exchange System, R. Schauer, R.Purtschert and D. Witt, (eds.) Nonprofit-Organisationen undgesellschftliche Entwicklung: Spannungsfeld zwischen Mis-sion und Okonomie, Johannes Kepler Universitat Linz: Uni-versitatsverlag Rudolf Trauner (2002) pp. 273–286.

48. W3C/XSL. Specification of XSL Standard. WWW Con-sortium (W3C) (2002), http://www.w3.org/Style/XSL (ac-cessed 2003-08-05).

49. J. Britt and T. Duynstee, Professional Visual Basic 6 forXML. Birmingham, UK: Wrox Press Ltd. (2000).

50. W3C/DOM. Specification of DOM Standard. WWW Con-sortium (W3C) (2002), http://www.w3.org/DOM (accessed2003-08-05).

51. M.E. Porter, Competitive Strategy: Techniques for AnalyzingIndustries and Competitors, 10th Edition. New York (NY),USA: Free Press (1998).

52. P. Kotler, Marketing Management, 11th Edition. Upper Sad-dle River, UK: Prentice Hall (2002).

53. R. Galliers (ed.), Information Analysis, Selected Readings.Boston (MA), USA: Addison-Wesley Publishing Company(1987).

54. P. Ballantyne, R. Labelle and S. Rudgard, Information andknowledge management: challenges for capacity builders,Policy Management Brief (11) (2000).

Springer