Revenue Authorities Digital Data Exchange (RADDEx) in the Making - Background, Strategy and Implementation
←
→
Page content transcription
If your browser does not render page correctly, please read the page content below
Revenue Authorities Digital Data Exchange (RADDEx) in the Making – Background, Strategy and Implementation RADDEx in the Making – Background, Strategy and Implementation October 2013
Table of Contents
TABLE OF CONTENTS ....................................................................................................................................................... 2
FIGURES.............................................................................................................................................................................. 3
TABLES ............................................................................................................................................................................... 3
1. INTRODUCTION............................................................................................................. 4
1.1. BACKGROUND ..................................................................................................................................................... 4
1.2. EATH’S APPROACH TO SOLVING THE PROBLEM ........................................................................................... 5
1.3. BENEFITS OF RADDEX 2.0.............................................................................................................................. 6
2. SECRETS TO RADDEX SUCCESS ..............................................................................10
2.1. POLICY .............................................................................................................................................................. 10
2.1.1. The RADDEx 1.0 approach: Buy in at the national level ......................................................... 10
2.1.2. The RADDEx 2.0 approach: Buy in at the regional level ......................................................... 12
2.2. RADDEX 2.0 ROLES & STRATEGY .............................................................................................................. 14
2.3. IT SYSTEM DESIGN, PROCUREMENT, AND IMPLEMENTATION ................................................................ 15
2.3.1. The RADDEx 1.0 "communicator" architecture .......................................................................... 15
2.3.2. The move to RADDEx 2.0 "regional customs management" architecture ...................... 18
2.4. HARDWARE PROCUREMENT ......................................................................................................................... 24
2.4.1. EATH’s role in the procurement ......................................................................................................... 24
2.4.2. Actual hardware specifications delivered for RADDEx 2.0 .................................................... 25
3. CHALLENGES AND LESSONS LEARNED................................................................26
RADDEx in the Making – Background, Strategy and Implementation October 2013
2
Figures
FIGURE 1: PRESIDENTS OF THE 5 EAC PARTNER STATES AT RADDEX 2.0 LAUNCH, ARUSHA TZ (NOV. 2012) .................... 6
FIGURE 2: PRESIDENT MWAI KIBAKI OF KENYA DELIVERING HIS RADDEX 2.0 LAUNCH SPEECH, ARUSHA TZ (NOV. 2011)
.............................................................................................................................................................................................................. 6
FIGURE 3: MONETIZING BENEFITS OF RADDEX 2.0, PART 1 ............................................................................................................... 8
FIGURE 4: MONETIZING BENEFITS OF RADDEX 2.0, PART 2 ............................................................................................................... 9
FIGURE 5: COMPONENTS OF RADDEX 2.0'S SUCCESS ....................................................................................................................... 10
FIGURE 6: 1ST RADDEX DEVELOPMENT WORKSHOP, ELDORET CUSTOMS OFFICE, KENYA (2006) ....................................... 12
FIGURE 7: 1ST MEETING OF RADDEX WORKING GROUP, ELDORET CUSTOMS OFFICE, KENYA (2006) .................................. 12
FIGURE 8: RADDEX 1.0 INSTALLATIONS (2010) & CONNECTING ROAD NETWORK ................................................................... 16
FIGURE 9: RADDEX 1.0 ARCHITECTURE ............................................................................................................................................. 17
FIGURE 10: RADDEX 2.0 ARCHITECTURE .......................................................................................................................................... 19
FIGURE 11: RADDEX 2.0 WORKSHOP SIMULATION, MOMBASA KENYA, TZ TEAM (2011) ...................................................... 22
FIGURE 12: RADDEX 2.0 WORKSHOP SIMULATION, MOMBASA KENYA, RW TEAM (2011) .................................................... 22
FIGURE 13: RADDEX 2.0 WORKING GROUP, ALL 5 PARTNER STATES AND EAC, MOMBASA KENYA (2011) ....................... 22
FIGURE 14: RADDEX 2.0 RA SOFTWARE DEVELOPERS, MOMBASA KENYA (2011) .................................................................. 22
FIGURE 15: DATED RADDEX 1.0 RACK MOUNTED SERVER AT URA .............................................................................................. 24
FIGURE 16: RADDEX 2.0 BLADE ENCLOSURE AT URA ..................................................................................................................... 24
Tables
TABLE 1: KEY STRATEGY DIFFERENCES BETWEEN 1.0 & 2.0 ........................................................................................................... 13
TABLE 2: RADDEX 2.0 POLICY ROLES................................................................................................................................................. 14
TABLE 3: KEY DISTANCES ON THE NORTHERN CORRIDOR................................................................................................................. 16
TABLE 4: VOLUME OF TRANSACTIONAL OPERATIONS PERFORMED BY CONTROL SERVER ........................................................... 20
TABLE 5: RADDEX 2.0 EXAMPLE SCENARIO ....................................................................................................................................... 21
TABLE 6: ALL FIELDS OFFICIALLY AGREED UPON FOR REGIONAL SHARING AMONG THE EAC ..................................................... 23
RADDEx in the Making – Background, Strategy and Implementation October 2013
3
1. Introduction
Information Communication Technologies (ICT) continue to impact the lives and lifestyles of people
across the globe. In developed countries ICT advances at ever-increasing speeds improving the
efficiency of existing business, creating new business and largely positively impacting the population.
However, in developing countries and among populations of poverty, the digital revolution has gone
by relatively unnoticed as the digital divide between the developed and undeveloped world continues
to grow. It is indeed the facilitating capacity of ICT that lends itself to the growth of the divide in
countries with access to these technologies. The most prominent example of the digital divide is
among the countries of the African continent.
EATH recognizes the vast potential of ICT applied to trade facilitation in East Africa and the
opportunity for substantive progress. Drawing on activities of EATH’s three main components to i)
reduce barriers to regional and international trade, ii) facilitate the efficiency and competitiveness of
key value chains, iii) ramp up trade and investment between the United States and East Africa, EATH
has identified specific areas that would greatly benefit from the introduction of ICT systems. These
systems are designed to enhance international management and communication, improve process
efficiency and ultimately place the nations of East Africa in a more competitive position in the world
market. Moreover, they are designed to meet the unique constraints of doing business in Africa.
1.1. Background
East Africa has the highest transport costs in the world where approximately 40% of the end cost of
goods can be attributed to transport. East African businesses are severely hampered by inefficient
trade facilitation systems that include transport logistics, administrative cross-border entry and exit
procedures and transit regulations. Delays at border crossings has long been identified as one of the
largest non-tariff barriers to trade in Africa. Some of the identified, contributing factors include
inefficient paperwork processes, lack of advance notification of goods, fraudulent declarations, lack of
efficient, international information exchange between Revenue Authorities and out of date or lack of
transit and trade statistics. One drastic improvement lies in developing a platform of efficient customs
and transit data exchange, management and reporting.
RADDEx (Revenue Authorities Digital Data Exchange) is an initiative which began among the
Revenue Authorities of the East African Community Partner States in collaboration with the East and
Central Africa Trade Hub (USAID). Its results encompass much more than a software product.
RADDEx in the Making – Background, Strategy and Implementation October 2013
4
RADDEx is a regional capacity building initiative resulting in increased awareness of the benefits of
regional cooperation, sensitization to the need for
legal reforms in the digital age, movement
towards customs functioning as a union and East African businesses are severely
finally a software solution owned, operated and hampered by inefficient trade
maintained by the Revenue Authorities. facilitation systems that include
The RADDEx initiative has always been viewed transport logistics, administrative
as the first step towards regionally managing cross-border entry and exit
customs data and operations throughout the EAC procedures and transit regulations.
customs union by promoting free and automatic
flow of customs data among the Partner States.
This regional connectivity in customs greatly contributes to more efficient and paper free processes at
borders as well as creating a transparent trading environment.
This enhancement in customs connectivity works towards realizing the vision of wholly integrated
border management.
1.2. The East Africa Trade Hub’s approach to solving
the problem
The East Africa Trade Hub (EATH) program has continued on where the ECA Hub left off in many
areas including providing technical assistance to the Revenue Authorities (specifically customs) of the
EAC. In assessing the status of the RADDEx initiative and the RADDEx 1.0 software a number of
comments were brought to light mainly by the public sector including:
Lengthy, country by country implementation leading to regional disharmony
Too heavy a workload for Revenue Authority (RA) ICT technical staff in development and
maintenance
Bilateral exchanges leading to:
o Lack of capacity for regional risk management
o No capacity for regional data mining
Growing set of user requirements has rendered complexity of a distributed model
unmanageable
Diminishing faith of the private sector due to technical difficulties
It was clear that RADDEx remained a high profile and necessary part of regional customs
management. It was also clear that there was a need for improvements both in strategy and product.
RADDEx in the Making – Background, Strategy and Implementation October 2013
5
ICT continues to advance rapidly in Sub Saharan Africa. Although not at the same level of speed and
reliability as the developed world, ICT infrastructure has already improved to support more advanced
environment appropriate solutions than RADDEx 1.0. Based on the successes and shortcomings of
RADDEx, EATH proposed a new strategy. This strategy included a partnership with the EAC
Secretariat and its customs department, technical assistance in policy development for the adoption of
RADDEx and provision of technical experts to develop a new centralized customs ICT management
system called RADDEx 2.0.
This EATH/EAC partnership, and top-down strategy with attention to political will as well as
technical excellence (outlined in greater detail later in this document) would eventually result in an
official launch of RADDEx 2.0 by President Kibaki of Kenya during a heads of state meeting in
Arusha, Tanzania in November 2012. This high profile event not only drew international, regional
attention but also solidified RADDEx 2.0 as the way forward for the EAC and did wonders to ensure
sustainability in the initiative through appropriate resource allocation.
Figure 1: Presidents of the 5 EAC Partner States at Figure 2: President Mwai Kibaki of Kenya delivering
RADDEx 2.0 launch, Arusha TZ (Nov. 2012) his RADDEx 2.0 launch speech, Arusha TZ (Nov.
2011)
1.3. Benefits of RADDEx 2.0
Trucks and their cargo travel on linear routes from city to city, country to country, as defined by the
road network. The efficiency of transporting goods is limited by countless external factors including
road conditions, vehicle condition, traffic laws, drivers, fuel capacity and very importantly, border
agencies including customs.
In contrast, information traveling via the Internet is blind to such constraints. It does not see countries,
roads, cities or borders, can travel globally blink of an eye and exist in multiple locations at the same
time. It is virtually limitless and unconstrained.
RADDEx ensures that goods in transit are never delayed due to a lack of information or gaps in
communication.
RADDEx in the Making – Background, Strategy and Implementation October 2013
6
RADDEx eliminates multiple preparation of the Single Administrative Document (SAD). RADDEx
allows for clearing agents to fill a single form at port of entry that can be used for the entire EAC
region. This reduction of paperwork, and the accompanying processing time, saves clearing agents up
to four hours at every border.
RADDEx enables the advance clearing of
goods across borders. Once a truck has lodged
RADDEx 2.0 saves businesses and
its initial customs declaration at port of entry, governments time and money by
all information regarding cargo is facilitating efficient cross-border trade
instantaneously relayed to the clearing agent at and transit through an ICT platform. It
the border. That agent can immediately start shortens cargo processing times and
clearing that cargo while the truck is still in reduces border delays.
transit. Advance completion of customs
declarations can constitute a 50 percent
reduction in time at borders. If the average clearance
time at the Malaba border is four hours, truckers using RADDEx should be able to clear the border in
two hours. Advance clearing is similar to checking-in online for a flight.
RADDEx reduces transit bond cancellation time by providing electronic proof that a consignment has
exited the transit country. Clearing agents no longer have to journey to borders or capital cities to
gather export certificates and reports. Those reports are available to Customs through RADDEx. In
addition to freeing up working capital sooner, electronic proof for bond cancellation saves clearing
agents excess travel and time.
RADDEx provides transparency. It reduces corruption through item-level tracking, removal of false
declarations, and customs user-audit trails. Accurate customs reports provide data for policy makers to
make sound decisions on public expenditure allocation.
The World Bank estimates that a loaded truck
transporting goods on the Northern Corridor
costs $384 per day of delay. In a joint Kenya
If RADDEx only saves 2 hours at the
Revenue Authority (KRA) /World Customs Malaba border alone, this equates to $32
Organization (WCO) Time Release Study in saved by an individual trucker on a single
2004, advance clearing (pre-lodging) at the crossing.
Malaba border was estimated to save 12 hours
of processing time. (In addition to advance
clearing, RADDEx also better prepares the customs unit for arriving goods.) If RADDEx only saves
RADDEx in the Making – Background, Strategy and Implementation October 2013
7
two hours at the Malaba border alone, this equates to $32 saved by an individual trucker on a single
crossing.
Figure 3: Monetizing Benefits of RADDEx 2.0, Part 1
RADDEx in the Making – Background, Strategy and Implementation October 2013
8
However, the volume of trucks passing through the Malaba border is approximately 1000 per day:
Figure 4: Monetizing Benefits of RADDEx 2.0, Part 2
RADDEx in the Making – Background, Strategy and Implementation October 2013
9
2. Secrets to RADDEx Success
RADDEx 2.0
Training &
Policy ICT
Capacity Building
Figure 5: Components of RADDEx 2.0's success
2.1. Policy
2.1.1. The RADDEx 1.0 approach: Buy in at the national level
Prior to the introduction of RADDEx, there was an air of doubt and hesitation surrounding customs
connectivity. Doubt that the different customs management systems in East Africa could ever talk to
each other, and hesitation as to whether or not valuable national customs data should travel country to
country over the internet. In 2005, it was the Revenue Authorities of the EAC (primarily Kenya and
Uganda) who began to actively seek a solution. They were determined to speed up border processing
times, eliminate the miles long lines of trucks at their borders, stamp out fraud and get away from
extensive paperwork. In this regard it was the RA’s that drove the mission to find a customs
connectivity solution and so it was the RA’s that were targeted in assistance. This was the beginning
of national to regional (bottom-up) approach for accomplishing customs connectivity.
RADDEx in the Making – Background, Strategy and Implementation October 2013
10In late 2005 the East and Central Africa Trade Hub (a USAID project) presented an ICT solution, a
proof of concept that showed a method to pass data between the unlike systems of Kenya Revenue
Authority’s newly implemented SIMBA 2005 and Uganda Revenue Authority’s older ASYCUDA++
system. With the technical communication
mystery solved, the concept of customs
connectivity was made a priority for both Working with each revenue authority at
Uganda Revenue Authority (URA) and the national level towards the goal of
KRA. In the excitement, it was no longer regional connectivity, RADDEx 1.0 was
a question of should it be done, it was one a bottom-up approach to a regional
of how quickly can it be implemented. In
solution.
2006, the ECA Hub went on to design a
system of middleware and web services
that would become RADDEx 1.0. It
appeared to be an ideal solution for the time with benefits including:
RADDEx was a methodology and defined a standard of communication in order to be a part
of the RADDEx network, rather than a plug and play application. An open source version was
made available to the RA’s if they preferred to start with a working platform.
RADDEx utilized very little bandwidth and did not require constant Internet connectivity.
RADDEx was free to be programmed in the software language of the RA’s choosing allowing
for extendibility and in-house maintenance. This led to versions of RADDEx in PHP, .NET
and Java.
An ambitious RA could join the RADDEx network at the speed that it prioritized its
connection to RADDEx.
The Revenue Authorities initially embraced this very individually driven system. It was quick to
implement and showed immediate results. Howeve,r the uniqueness of the individually driven RA
implementations went on to illustrate:
Huge gaps in competencies between RA’s resulting in regional disharmony.
Overloaded RA ICT staff in development and maintenance.
Loss of a regional vision through multiple quick fixes to accomplish bilateral communications.
Unexpected growing interest in the ability to mind the data being exchanged by all
departments of customs, and a resulting list of upgrades.
In addition, the EAC Secretariat although included in the process was not seen as a driver of the
initiative and therefore did not fully support the efforts.
RADDEx in the Making – Background, Strategy and Implementation October 2013
11Figure 6: 1st RADDEx development workshop, Eldoret Customs Office, Kenya (2006)
Figure 7: 1st meeting of RADDEx working group, Eldoret Customs Office, Kenya (2006)
2.1.2. The RADDEx 2.0 approach: Buy in at the regional level
With the prominence of the fully-fledged customs union under the EAC, it became clear that a
technically and politically successful regional program for the EAC Partner States would need to be
driven and championed by a Regional Economic Community. This would move leadership away from
nationalistic agendas into the hands of a regional agenda. In addition, the technical shortcomings of
RADDEx 1.0 in a rapidly advancing field
including necessitated the need to revisit
In contrast to RADDEx 1.0, EATH
customs connectivity.
employed a top-down approach in the
The EATH Program partnered with the EAC implementation of RADDEx 2.0 starting
Secretariat with a priority agenda item to
at the EAC Secretariat.
develop a regional policy for the adoption and
usage of regional customs connectivity among
the Partner States under the RADDEx
RADDEx in the Making – Background, Strategy and Implementation October 2013
12initiative. This partnership included the provision of technical expertise in matters of policy, system
governance, action plans and the development of a centralized ICT system for both the regional
exchange of customs data as well as the reporting and mining of the data in the interest of real time
trade statistics.
1.0 2.0
RA (national) initiative EAC driven (regional) initiative
Country by country roll out Regional roll out
No reporting capability Fully comprehensive regional reporting
Distributed control Central control
Multiple systems for user One system for users
Multiple training courses / manuals One training course / one set of manuals
Table 1: Key strategy differences between 1.0 & 2.0
RADDEx in the Making – Background, Strategy and Implementation October 2013
132.2. RADDEx 2.0 Roles & Strategy
Revenue Authorities EAC EATH
Agree on a common regional policy for Through facilitation of regional meetings Work with the EAC, RA’s and other donors to
adoption and usage of the system the EAC will generate and document the coordinate the initiative.
(facilitated by the EAC.) policy for adoption and usage of the Support the RA’s to gather comprehensive user
Participate in product development system. and reporting requirements for the system.
workshops. EAC in cooperation with the RA’S and Facilitate development workshops for RA
Using RADDEx (or other) technologies EATH Program will provide sensitization developers for product development and training.
ensure that required customs data is up to and comprehensive training. Contribute to development of the platform through
date and available to the centralized provision of expert software engineers.
platform at all times. Provide core operational hardware.
Facilitate appropriate telecommunications Support RA’s in roll out the system in the East
infrastructure and hardware at identified African Community.
critical border posts by working with EATH.
Institutionalise RADDEx so that it is a part
of customs procedure not an option.
Table 2: RADDEx 2.0 Policy Roles
RADDEx in the Making – Background, Strategy and Implementation October 2013
142.3. IT System Design, Procurement, and
Implementation
RADDEx 1.0 or 2.0 are ultimately methodologies for automated communication between like and/or
unlike systems. They were not intended to be all encompassing, out of the box software applications.
The RADDEx initiative has always been a mission of capacity building amongst the revenue
authorities so that they may sustain and extend the initiative in the future. Development and
implementation of RADDEx continues to require expert knowledge in software development, web
applications, database architecture, network administration and project management.
2.3.1. The RADDEx 1.0 "communicator" architecture
The Partner State Revenue Authorities unanimously adopted RADDEx 1.0 as a regional solution in
June 2006. It was proven to be a relatively easy model to implement and one that was suited to the
telecommunications and ICT infrastructure of the time. That is, RADDEx required minimal hardware,
minimal bandwidth and functioned very well even when internet connectivity was sporadic.
The best working example of RADDEx 1.0 was the bilateral communications that took place daily
between the Kenya Revenue Authority and Uganda Revenue Authority starting in 2007 and running
through implementation of RADDEx 2.0 today. In addition to communication of data, a simple web
application ran on the RADDEx web server that provides an interface to both customs officers and
clearing agents.
RADDEx in the Making – Background, Strategy and Implementation October 2013
15Figure 8: RADDEx 1.0 installations (2010) & connecting road network
Mombasa Nairobi Malaba Kampala Gatuna Kigali Akanyaru Bujumbura
Mombasa 0 484 923 1142 1572 1653 1807 1922
Nairobi 484 0 439 658 1088 1169 1323 1438
Malaba 923 439 0 219 649 730 884 999
Kampala 1142 658 219 0 430 511 665 780
Gatuna 1572 1088 649 430 0 81 235 350
Kigali 1653 1169 730 511 81 0 154 269
Akanyaru 1807 1323 884 665 235 154 0 115
Bujumbura 1922 1438 999 780 350 269 115 0
Table 3: Key distances on the Northern Corridor
RADDEx in the Making – Background, Strategy and Implementation October 2013
161
The RADDEx architecture of RADDEx 1.0 is a distributed system communicating over a
2
standardized methodology called web services .
Although the original architecture of RADDEx 1.0 provided for a regional, distributed system through
the use of comprehensive tracking of data transmission, the time constraints and pressure of an
immediate solution largely transformed communications to a more limited bilateral arrangement as in
the case of KRA / URA. With a growing list of requirements from various departments of customs
and the critical regional need for transit and trade statistics the RADDEx 1.0 architecture can no
longer address the requirements while maintaining a manageable level of complexity.
Figure 9: RADDEx 1.0 Architecture
1
A system where hardware and software components located at networked computers communicate and coordinate their
actions by passing messages. ‐ (Christoph Schuba, Sun Microsystems)
2
A software system designed to support interoperable machine‐to‐machine interaction over a network. Web services
provide a standard means of interoperating between different software applications, running on a variety of platforms and/or
frameworks. – (World Wide Web Consortium | http://www.w3.org/)
RADDEx in the Making – Background, Strategy and Implementation October 2013
172.3.2. The move to RADDEx 2.0 "regional customs
management" architecture
The RADDEx 2.0 network is a unique combination of centralized and distributed architecture. Each
Partner State Revenue Authority manages a server within their own LAN which functions as a tool for
customs operations. The application running on this local RA server will be accessed by customs
officers and clearing agents only within the borders of their country and used in the day to day
business of customs. These servers are called the Satellites in the RADDEx 2.0 network. Satellites
communicate only with the central server and not with each other. The requirements for the Satellites
have been determined by the individual Partner States.
Control of the regional flow of information (between countries) is managed centrally by the Control
server. The Control server holds regional customs information and determines what to get from each
of the Satellites and what to put on each of the Satellites. It is essentially the controller of information
flow and a central repository of regional data. In addition the Control server will host a user reporting
application though we expect this traffic to be minimal.
RADDEx 2.0 is a modern web application and scalable by design. It will be able to handle increasing
capacities far into the foreseeable future.
In designing the methodology for automated communication between differing systems running on
differing platforms many models were considered. Arrival at the RADDEx 2.0 architecture was
dependent primarily on:
1. Communication independent of platform
There is no uniformity surrounding adoption of automated customs systems (i.e. KRA has
adopted web based SIMBA 2005 while many other Revenue Authorities have adopted
ASYCUDA++ and still others different systems.)
2. Sustainability at ICT capacity of Revenue Authority
Revenue Authorities at time of inception were only willing to accept technical support for
this initiative if it could be proven to be sustainable through hands on involvement of their
ICT staff
3. Reliability of telecommunications infrastructure
This key weakness in Sub Saharan Africa is the primary reason that RADDEx has never
been built using straightforward, centralized web architecture prevalent in the developed
world.
4. Speed of implementation.
RADDEx in the Making – Background, Strategy and Implementation October 2013
18Figure 10: RADDEx 2.0 Architecture
RADDEx in the Making – Background, Strategy and Implementation October 2013
19Projected Transaction Volume
There are an estimated 1000 transactions daily originating in Kenya and approximately 400
originating in the other Partner States. Of the 1000 transactions originating in Kenya 700 will
terminate in Uganda and the remaining 300 further inland as far as Burundi. This allows us to project
(generously) a volume of transactions performed at the Control server:
Gets Puts
Kenya 1000 400
Uganda 200 1000
Tanzania 100 100
Rwanda 50 220
Burundi 50 80
TOTALS 1400 1800
Table 4: Volume of transactional operations performed by Control Server
The projections above illustrate approximately 3200 daily transactions through the central control
server. Each transaction is generally a very small transmission of between 10KB and 50KB. This
leads to a figure generously estimated at 160MB of total bandwidth.
Definitions of what constitutes a high traffic web application/site are subjective. It is generally
considered that 10,000+ unique visits is high traffic. Recurring transactions of less than 5,000 per day
is low volume.
Concurrent Connections
As each Partner States hosts its own operations server, the demand for concurrent connections to the
Control server is minimal and limited to the Satellites and users performing reports. It is therefore not
expected to exceed 15 at any time.
The hybrid architecture (centralized and distributed) allows for a unique case of redundancy. Due to
the fact that the declaration data will be transmitted far in advance of arriving cargo, downtime at the
centralized server will allow a window of time (in the order of days) where the system will function
normally at the operations level. Therefore, excessive mirroring and fail overs are not necessary. It is
recommended that at maximum a single mirror is implemented.
Example scenario
RADDEx 2.0 will operate in all five Partner States completely independently. However, the
architecture is designed so that the system is intricately linked through the Central Control Server. We
refer to Partner States’ local RADDEx servers as Satellites. The Central Control Server will be
referred to as Control. Control initiates a health check on each satellite periodically to ensure that all
RADDEx in the Making – Background, Strategy and Implementation October 2013
20systems are running. Following is an example scenario of the steps that the system takes in managing
regional flow of customs data:
A new declaration is lodged in a National Customs System assessed and released.
The Central Control Server initiates a poll of the Partner States’ satellites. The poll requests transactions since last poll.
Each satellite returns released declarations.
Control checks if a RADDEx id exists. The declaration is new so Control assigns the declaration a RADDEx id, and each
item a RADDEx item id. This is critical for reconciliation purposes.
Control examines final destination and maps the route, determining which countries the goods will travel through.
Control pushes the declaration to the affected satellites.
The RADDEx 2.0 system is now completely in sync.
An agent retrieves a lodged declaration through accessing the local Satellite. He downloads the appropriate format, which
automatically preserves the RADDEx id and the RADDEx item ids.
The agent lodges the declaration in the local National Customs System.
Control initiates a poll of the Satellites. The poll requests transactions since last poll.
Each satellite returns released declarations.
Control checks if a RADDEx id exists. The declaration exists so Control verifies the declarations against the previous
record and each item.
If discrepancies exist, the declaration is flagged. Otherwise this declaration is pushed to the affected satellites and
associated with the previous declaration entry.
The RADDEx 2.0 system is now completely in sync.
Table 5: RADDEx 2.0 example scenario
RADDEx in the Making – Background, Strategy and Implementation October 2013
21Figure 11: RADDEx 2.0 workshop simulation, Figure 12: RADDEx 2.0 workshop simulation, Mombasa
Mombasa Kenya, TZ team (2011) Kenya, RW team (2011)
Figure 13: RADDEx 2.0 working group, all 5 Figure 14: RADDEx 2.0 RA software developers,
Partner States and EAC, Mombasa Kenya (2011) Mombasa Kenya (2011)
RADDEx in the Making – Background, Strategy and Implementation October 2013
22Main declaration fields Item fields
1 Exporter name 1 Item number
2 Exporter tin (Taxpayer Identification Number) 2 Marks and numbers of packages
3 Exporter address 3 Commercial description
4 Importer name 4 Commodity code
5 Importer tin 5 Customs procedure code
6 Importer address 6 Item gross weight
7 Clearing agent name 7 Item net weight
8 Clearing agent tin 8 1st supplementary quantity/units
9 Agent address 9 Type of packaging
10 Clearance office 10 Number of packages
11 Frontier or border office 11 Country of origin
12 Regime code 12 Preference code
13 Registration date 13 Item fob value
14 Voyage or vehicle number 14 Currency code
15 Date of departure 15 Exchange rate
16 Bill of lading 16 Item freight
17 Manifest number 17 Item insurance
18 Country of last consignment 18 Item other charges
19 Country of final destination 19 Customs value
20 Port of destination 20 Attached documents code
21 Place of discharge 21 Preceding documents references
22 Mode of transport at the border 22 Item import duty
23 Nationality of transport 23 Item excise duty
24 Seal number 24 Item vat
25 Country of transit
26 Total number of items
27 Total number of packages
28 Total gross weight
29 Location of goods
30 Warehouse code
31 Period/time in warehouse/transit
32 Valuation method
33 Total fob
34 Total freight
35 Total insurance
36 Terms of delivery code
37 Terms of payment
38 Account holder no. Prepayment account no
39 Bank/branch code
40 Bond number
41 Bond amount
42 Total customs value
43 Total import duty
44 Total excise duty
45 Total value added taxes
Table 6: All fields officially agreed upon for regional sharing among the EAC
RADDEx in the Making – Background, Strategy and Implementation October 2013
232.4. Hardware Procurement
It was determined early on that the ICT infrastructure at the Revenue Authorities would need to be
updated or added on to in order to meet the needs of additional systems.
2.4.1. EATH’s role in the procurement
The EATH Program proposed that they (EATH) recommend, procure and donate hardware for the
express purpose of the RADDEx 2.0 implementation. This ensuing agreement to procure hardware
was important for multiple reasons including:
The gesture cemented EATH’s dedication to the initiative and strengthened the working
partnership both with the EAC and the Partner State Revenue Authorities,
A procurement left in the hands of government agencies could take many months and even
years to realize. EATH was able to complete the procurement in a matter of weeks.
Eliminated any hardware incompatibilities and sourcing of unnecessary hardware.
Recommendations were initially made to the EAC Secretariat and Partner States to install a single,
dedicated, rack mounted server to run RADDEx. The recommendation was made for the simplicity of
the procurement, maintenance and training on the equipment. This was however rejected due to the
internal policy constraints in place at the multiple ICT offices of the Revenue Authorities. It was then
agreed that each individual Revenue Authority put forth their requirements which could then be vetted
by EATH, amended if necessary, and procured by EATH.
Figure 15: Dated RADDEx 1.0 rack mounted server Figure 16: RADDEx 2.0 blade enclosure at URA
at URA
RADDEx in the Making – Background, Strategy and Implementation October 2013
242.4.2. Actual hardware specifications delivered for RADDEx
2.0
EAC Secretariat BURUNDI KENYA RWANDA TANZANIA
BladeSystem C3000 Rackmounted HP BladeSystem C3000 Rackmounted HP Rackmounted HP
Enclosure ProLiant DL380 G7 Enclosure ProLiant DL380 G7 ProLiant DL380 G7
HP BLc3000 CTO Encl Server HP BLc3000 CTO Encl Server Server
HP BLc QLogic HP G7 Rack Proliant HP BLc QLogic HP G7 Rack Proliant HP G7 Rack Proliant
QMH2462 FC HBA Opt DL380 G7 Intel Xeon QMH2462 FC HBA Opt DL380 G7 Intel Xeon DL380 G7 Intel Xeon
Kit E5620 Quad Core 2.40 Kit E5620 Quad Core 2.40 E5620 Quad Core 2.40
HP BLc VC Flex-10 GHz HP BLc VC Flex-10 GHz GHz
Enet Module Opt HP 8GB 2Rx4 Enet Module Opt HP 8GB 2Rx4 HP 8GB 2Rx4
HP BLc VC 8Gb FC 20- Registered (RDIMM) HP BLc VC 8Gb FC 20- Registered (RDIMM) Registered (RDIMM)
Port Opt Kit PC3-10600R-9 Kit Port Opt Kit PC3-10600R-9 Kit PC3-10600R-9 Kit
HP 3y 4h 24x7 HW HP 300GB 6G SAS 10K HP 3y 4h 24x7 HW HP 300GB 6G SAS 10K HP 300GB 6G SAS 10K
Support 2.5in DP ENT HDD Support 2.5in DP ENT HDD 2.5in DP ENT HDD
c3000 Enclosure HW HP Slim 12.7mm SATA c3000 Enclosure HW HP Slim 12.7mm SATA HP Slim 12.7mm SATA
Supp DVDRW Optical Kit 6 Supp DVDRW Optical Kit 6 DVDRW Optical Kit 6
HP BL460c G7 CTO HP 460W Hot Plug HP BL460c G7 CTO HP 460W Hot Plug HP 460W Hot Plug
Blade Power Supply Blade Power Supply Power Supply
HP BL460c G7 E5620 HP 460W HE 12V HP BL460c G7 E5620 HP 460W HE 12V HP 460W HE 12V
FIO Kit Hotplg AC Pwr Supply FIO Kit Hotplg AC Pwr Supply Hotplg AC Pwr Supply
HP 4GB 2Rx4 PC3- Kit (redundant) HP 4GB 2Rx4 PC3- Kit (redundant) Kit (redundant)
10600R-9 Kit 10600R-9 Kit
HP 300GB 6G SAS 10K HP 300GB 6G SAS 10K
2.5in DP ENT HDD 2.5in DP ENT HDD
HP BLc QLogic HP BLc QLogic
QMH2462 FC HBA Opt QMH2462 FC HBA Opt
Kit Kit
BL4xxc Svr Bld HW BL4xxc Svr Bld HW
Support Support
RADDEx in the Making – Background, Strategy and Implementation October 2013
253. Challenges and Lessons Learned
Capacity building in software development and ICT
Although the core of sustainability lies in building appropriate capacity there is a limit to capacity
building under short term (4-5 years) projects as it relates to the discipline of software development
and ICT. This is very dependent upon the starting base knowledge of the trainees. The base
knowledge in the public sector (specifically revenue authorities) in East Africa is not at a sufficient
level to absorb and utilize the trainings required of a complex, medium to large-scale software
development initiative. Therefore, it is recommended that initiatives of this nature are delivered to
public sector in a finished state and capacity building is limited to user operation of the system and
small-scale maintenance.
Harmonization of requirements
In dealing with multiple countries, administrations and languages a harmonized set of requirements is
one of the most difficult achievements. Avoidance of circular discussion and standoffs necessitates a
strong chairperson representing the EAC regional body. This role cannot be undertaken either by a
representative of the technical assistance program or an individual Partner State. This chair should be
the voice of authority and requirements signed off on should not be revisited.
Institutional staff turnover
Of the original RADDEx team of 2006, there are as few as three remaining members in a team of 25
or more today. Institutional handoffs were not suitable (or non-existent) and institutional knowledge
of the project was lost resulting in huge losses of time and capacity. Questioning past project members
revealed the primary reason for this was dismally low wages for ICT staff in the Revenue Authorities
resulting in private sector poaching of experienced staff.
Public sector time resources
Though the RADDEx concept has been embraced by East African revenue authorities, appropriate
human resources (i.e. number of people and time) are not allocated to the project and are still not
available. This has resulted in long delays, complete project team turnover and a lack of sustainability.
Where possible public sector should be restricted to requirements gathering and utilization of the end
product and not delve into the actual product development. Where possible, it is recommended that in
long-term, public sector, ICT implementations the donor program second a staff member for as long
RADDEx in the Making – Background, Strategy and Implementation October 2013
26as possible to each of the benefiting organizations to increase institutional knowledge, ensure proper
training, handoff and appropriate resources are allocated.
Use of in-house expertise on product development outside of original
intentions
ICT is a crosscutting theme on many development projects today and very often a “quick win.” For
this reason, ICT resources are often called into play on projects outside of the original intentions. This
is a poor strategy that results in overstretched employees, poor attention to detail and inferior delivery.
An ICT add-on should be handled like any other project with appropriate resources allocated and
extra time, budget and resources planned for.
RADDEx in the Making – Background, Strategy and Implementation October 2013
27You can also read
