A Short History of AMP Technology

In May 2005, the Government of Ethiopia launched the inaugural Aid Management Platform (AMP). Since then, a community of over 25 partner governments has seen each technical change and enhancement come to fruition, playing a crucial role in shaping each program iteration.

But for those who haven’t watched AMP grow into a mature program offering over the last 14 years, we’re providing an overview of AMP’s technical evolution, outlining challenges, opportunities, and lessons learned from building a large-scale, needs-driven product for our partners.

Figure 1: The Basics of AMP

AMP Early Days

AMP was developed to fill an unmet need to increase country ownership of aid effectiveness and coordination.The platform expansion from a single implementation to 15 countries was rapid – happening in a span of just 4 years, and has continued to grow beyond that.

Accelerated growth meant an ever-expanding, increasingly complex data model, that needed to be adapted for each country context. At times, change requests from almost two dozen country partners had to be integrated into weekly stable builds – think of dinner rush in a buzzing (and relatively new!) restaurant kitchen. AMP is as dynamic and complex as its users – and we’ve learned that building stable code for an extensive platform, while maintaining the flexibility and agility necessary to fit each country’s needs, requires patience, determination, and a dose of humility.

To meet the challenge of rapid growth, we focused on streamlining processes – including the AMP code release – and organizing new requests in Jira tickets, grouped by requesting country and software version.

To make the process even more streamlined, DG adopted the Scrum methodology in early 2013. Scrum facilitates our communicative, iterative, and adaptive approach to handling client requests, and aligns with our partnership-centric approach in projects.

Ongoing Updates

When AMP began, support for version control was rudimentary. We initially used CVS (the very first version control system available!), migrating to Subversion in 2008, and again to Git in 2016. Git allows us flexibility in developing new features, while also saving time providing hotfixes – quick fixes that solve problems in up-and-running code. Similarly, we started using Jenkins as our continuous integration tool. Using Jenkins and Git also provides our quality assurance team with increased flexibility.

As a user-driven team, we are constantly considering user requirements and environment limitations. In 2016, with support from USAID’s Higher Education Solutions Network through the AidData Center for Development Policy, DG enhanced AMP’s GIS module based on findings from country-level research on how development data are used in Senegal, Timor-Leste, and Honduras. The GIS module meets development actors’ need for more customized analysis tools.

We’ve also evolved according to user requirements in building the IATI Import Tool, which is open source and can be extended to import IATI activities into any AIMS. We recognize the importance of data standards such as the IATI Data Standard to the development community, and this publicly-available tool enables integration of projects reported to IATI into AMP.

Additionally, to meet environmental challenges of internet speed and reliability, we developed AMP Offline to enable users with limited or unreliable internet connections to use AMP.

Platform and Database Usage

To avoid reinventing the wheel, we use open source frameworks – providing state of the art functionality to help users achieve their goals, while also optimizing software development.

AMP is built using the Java platform, and we’ve seen the Java ecosystem evolve – from plain JSP files and Struts back in 2005, to Apache Wicket in 2010, and APIs in 2012. We started building APIs with the IATI Import tool and with redesigning the reporting framework, and as for databases, we’ve moved from MySQL to PostgreSQL.

In addition to iterating on technology itself, the AMP team also continuously improves the modules making up the platform – for example, in building a new report engine. In reengineering how information is reported throughout the system’s modules, we’ve drastically improved the speed and stability of one of AMP’s core modules.

AMP in 2018 and Beyond

By constantly updating our technology and methodology, the AMP team has become more efficient in producing cost effective software that meets specific user requirements. The challenges that have come along with building and maintaining AMP have been integral to not only the evolution of the product, but to DG organizationally as well. Many of DG’s most valued lessons learned – like how to effectively engage with and provide support to governments throughout long and challenging implementations – have been learned from AMP.

Building on enhancements like the GIS module, in 2017, we integrated AMP with Uganda’s DMFAS system and are working to pull AMP data into its Programme Based Budgeting System (PBS), further facilitating linkages between AMP and other aid and debt management systems. In the coming year, we’re planning on updating our South South Cooperation Module for Haiti’s AMP. We’re also continuing to contribute to the IATI community: ground truthing the standard, building tools to improve data quality and usability, and supporting governments to use IATI in country systems.

We are eager and enthusiastic to continue sharing news and insights on the direction AMP is taking – we will continue to innovate in the AMP system, focusing on streamlining maintenance; empowering governments and partners to “localize” AMP; and phasing out DG support. Stay tuned for more updates in the upcoming months.

This blog is the third in a series of posts from our AMP Retrospective. Read the first post, Our Partnership Approach: 15 Years of Sustainable Collaboration in AMP, and the second post, Nurturing a Healthy AMP Ecosystem – and stay tuned for a final post in the coming weeks.