Revenue Authorities Digital Data Exchange (RADDEx) in the Making - Background, Strategy and Implementation

 
Revenue Authorities Digital Data Exchange (RADDEx) in the Making - Background, Strategy and Implementation
Revenue Authorities Digital Data
Exchange (RADDEx) in the Making –
Background, Strategy and
Implementation

RADDEx in the Making – Background, Strategy and Implementation   October 2013
Revenue Authorities Digital Data Exchange (RADDEx) in the Making - Background, Strategy and Implementation
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
Revenue Authorities Digital Data Exchange (RADDEx) in the Making - Background, Strategy and Implementation
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
Revenue Authorities Digital Data Exchange (RADDEx) in the Making - Background, Strategy and Implementation
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
Revenue Authorities Digital Data Exchange (RADDEx) in the Making - Background, Strategy and Implementation
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
Revenue Authorities Digital Data Exchange (RADDEx) in the Making - Background, Strategy and Implementation
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
Revenue Authorities Digital Data Exchange (RADDEx) in the Making - Background, Strategy and Implementation
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
Revenue Authorities Digital Data Exchange (RADDEx) in the Making - Background, Strategy and Implementation
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
Revenue Authorities Digital Data Exchange (RADDEx) in the Making - Background, Strategy and Implementation
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
Revenue Authorities Digital Data Exchange (RADDEx) in the Making - Background, Strategy and Implementation
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
                                                                                                    10
In 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
                                                                                                        11
Figure 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
                                                                                                      12
initiative. 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
                                                                                                       13
2.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
                                                                                                                                                         14
2.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
                                                                                                     15
Figure 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
                                                                                                             16
1
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
                                                                                                                        17
2.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
                                                                                                         18
Figure 10: RADDEx 2.0 Architecture

RADDEx in the Making – Background, Strategy and Implementation   October 2013
                                                                                19
Projected 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
                                                                                                           20
systems 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
                                                                                                                                    21
Figure 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
                                                                                                    22
Main 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
                                                                                                               23
2.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
                                                                                                     24
2.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
                                                                                                   25
3. 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
                                                                                                      26
as 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
                                                                                                        27
You can also read