APIs and API gateways are neither new nor innovative technologies. The innovation and value of APEX however, comes from making these technologies more accessible and increasing their adoption in government. With this mind, we built APEX a little differently from most government products:

BUILT WITH THE USER IN MIND

APEX was built to remove barriers of entry to agencies using the platform. The APEX user portal was designed with a focus on user experience to be clean and easy to use. Through the portal, users can access a repository of knowledge on APIs and the platform. They can also perform self-service registration and request access to APIs of other agencies. This ensures agencies are able to begin using the data they need without much administrative overhead.

BUILT TO PROMOTE SHARING, NOT SILOS

APEX aggregates all APIs served through it in a catalogue. Users can browse and search the catalogue for relevant APIs which may spark ideas for collaboration with other agencies.

BUILT FOR EXTENSIBILITY

Unlike many government projects, APEX was built by an inhouse engineering team using the Agile methodology. This allows APEX to rapidly evolve with new features to meet new needs. APEX was also built on a micro-services architecture powered by RESTful APIs. This allows APEX to easily integrate with new systems both upstream and downstream.

BUILT TO SCALE INTELLIGENTLY

The small size of the APEX team would make it prohibitively slow to manually deploy and configure additional servers to meet demand from new projects. The APEX team has automated this process so that our systems can be scaled up or down to meet demand through mere mouse-clicks.

BUILT TO MAKE SECURITY SIMPLE

Government standards on security are by necessity strict. However, these standards can be at times byzantine and intimidating. APEX fulfils many of auditing, logging and infrastructure requirements imposed by the standards, allowing agencies to be conformant without additional effort. Agencies’ data can also be protected using out-of-the-box authentication polices, while their systems are protected from surges in API calls through rate-limiting polices.

APEX was launched in July 2017 and is now steadily acquiring new users. APEX has achieved its vision of allowing data to be shared between the isolated government intranet and the public internet by providing a bridge between the two networks in a safe and secure setup. Government agencies can choose to share their data by publishing APIs on our API Catalogue which is browsed by other agencies to identify data sharing opportunities. Data sharing is done securely through industry standard security protocols for APIs and round-the-clock monitoring and logging to prevent unauthorised access and hacking attempts. The APEX platform is made easy to use for both technical and non-technical users via the APEX user portal. The portal provides a repository of information to guide users on how to onboard as data consumers or providers. Users can also use the portal to seamlessly register for an APEX account and request for access to APIs. In addition, users can also view usage information of their APIs as well file service requests and provide feedback to the APEX team through the portal. APEX followed the following steps in moving from conception to launch:

IDENTIFYING AN OPPORTUNITY

APEX began as a small feature contained within a platform-as-a-service (PAAS) product. The feature allowed services hosted on the PAAS to expose APIs to external services. However, it became evident that the API hosting technology could be extended to meet a wider need across government agencies for a simple way to share data. APEX was thus spun off as a separate project with a much more ambitious scope.

SCOPING OUT THE PROBLEM, RECOGNISING CONSTRAINTS

With an ambitious scope and timeline, it was important to define the minimum feature set for APEX. As part of this planning, challenges to the project such as bridging an internet-intranet separated infrastructure and complying to strict security standards were identified. These constraints shaped the architecture and design of APEX.

SURVEYING AVAILABLE TECHNOLOGY

With clear requirements in mind, the APEX team explored open-source and commercial API gateway technology. This exploration focused on figuring out how to leverage available technology for speed while adapting the technology to our unique requirements. Many existing solutions did not cater for our use cases such as having separated API gateway instances for each user project. The team had to design solutions to fill such gaps in available technology. STARTING SMALL The APEX development team adopted the Agile development approach to design, build and validate features through iterative work cycles. This methodology pushed the team to regularly deliver incremental features that built up towards our minimum viable product. THINKING ABOUT SCALE Once a basic feature set was achieved, the focus turned to ensuring that the operation, stability and performance of APEX would not be compromised as our user base grew. The team invested heavily in automating many of APEX's operating processes to ensure that our systems could be scaled rapidly to meet user demand. We also began building up our monitoring capabilities so that system issues could be quickly detected and addressed to maintain stability.

TESTING IN THE REAL WORLD

As APEX took shape, the team partnered with pilot projects to identify issues early and incorporate feedback into future feature designs. This phase was crucial in helping the team to improve usability and augment our product with commonly requested features. Even today, months after its launch, APEX continues to evolve in response to the constantly changing needs of our users. Apex’s professional services team regularly engages our users in dialogues to better understand their needs in order to develop user-centric features.

COLLABORATING FOR EFFECTIVE DEVELOPMENT

The APEX team worked in close collaboration with members of another project team within the same department. We cooperated on code modules that could be reused by both projects. By sharing code, technology and skill sets, we were able to both improve the quality of our work and reduce development time.

PARTNERING FOR PRODUCTION READINESS

The APEX team partnered with another division within the organization on on-boarding pilot projects. This occurred early in our development cycle while the APEX product was not stable nor feature complete, and when the pilot projects were still in development. These pilot projects helped us to test and stabilise our system. In addition, we were able to work with the pilot projects to incorporate features that they needed into our initial release. This partnership resulted in APEX becoming a more robust and full-featured product.

STAKEHOLDER SUPPORT

Our stakeholders provided the mandate and monetary resources which enabled us to embark on building APEX. They also gave us freedom to adapt and augment the product as we discovered new needs.

USER FEEDBACK

The APEX team was deeply involved in the on-boarding of our initial users. Through their feedback, we were able to discover inadequacies in the usability and workflows of the APEX user portal. We have since addressed these issues and provided more documentation and guides to empower new users to use APEX seamlessly.

PARTNER-DRIVEN VALUE CREATION

Many of our users have become trusted partners. Their positive experience with APEX has spurred them to readily suggest new features that would improve their services. By gathering the suggestions of many users across different agencies, we are able to identify high-value features that can be added to APEX to fulfill the needs of many users.

RAPID ADOPTION

In the 2 months since its launch APEX has on-boarded 9 projects from across 5 agencies. These projects served a total of more than 625K API calls last month. These figures are growing rapidly as APEX gains traction as a reliable API platform.

PRIVATE-PUBLIC SECTOR COLLABORATION

APEX bridges the physical separation between the government intranet and public internet. This makes it possible for government agencies to publish APIs to share data hosted in the intranet with commercial entities with services deployed on the internet. An example of this would be one of our pilot projects - myInfo. myInfo was developed to share basic citizen personal data hosted in agency databases with banks to facilitate consumer bank account creation and bring convenience to citizens.

REDUCED DEVELOPMENT COSTS FOR USERS

APEX removes the need for users to handle many of the security challenges of serving APIs to a large consumer base as part of the development of their own projects. APIs served through APEX can be protected through appropriate authentication polices to ensure only authorised applications may access data. API calls through APEX are rate-limited to prevent users' servers from being crippled by large number of API calls. All API calls through APEX are also audited and logged to provide tracking on how data is accessed.

PROPAGATION OF API EXPERTISE

The APEX professional services team provides training sessions to API provider agencies and their data consumers. These sessions transfer basic knowledge to participants on how to use and publish APIs effectively. The professional services team can also be engaged by agencies for in-depth sessions to enhance the design of their APIs to meet leading industry standards. Such services offered by the APEX professional services team increase the general level of API expertise across government agencies.

ADHERING TO GOVERNMENT STANDARDS

APEX faced challenges conforming to government security standards while providing the feature set required for seamless data-sharing between agencies. We addressed this challenge by consulting security experts to distill what was essential in preserving the security of our systems. In cases where the standards did not clearly apply to our product, we were careful to document measures taken to safeguard our systems.

MANAGING USER GROWTH

A challenge that the APEX team manages daily is that of scalability - both scaling our systems to adapt to demand and maintaining system stability as our user base grows. To handle the former challenge, we have automated the deployment and configuration of most of our subsystems to quickly and reliably scale up to meet demand. To maintain system stability, we are constantly enhancing our monitoring capabilities to ensure that we catch and address any system issues in a timely manner.

CLEAR VISION

APEX succeeded in gaining traction because it was conceived to meet a growing need - government agencies needed the technology to efficiently share data and systems to present more complete and citizen-centric services. Capitalising on this opportunity gave the APEX team a clear vision of our minimal viable product and the impetus to deliver it with speed.

TEAM-DRIVEN INNOVATION

APEX achieved quality and usability because it was built by a team with the skills and desire to constantly improve the product. Having a diversity of skill sets allowed us to identify possible enhancements from many angles - usability, stability, security, maintainability, etc. Freedom to self-manage allowed the team to experiment, fail fast and regroup quickly to realise its vision of what would make the product great.

REDUCING BUREAUCRATIC OVERHEAD FOR PUBLIC SERVANTS

APEX is a model of how innovation can occur within strict restrictions. The team has navigated extensive government procedures and standards to unravel what it means to share data securely. More importantly, products such as APEX reduce bureaucratic overhead for users by helping them conform to government standards with minimal effort.

ENABLING A CULTURE OF COLLABORATION

APEX has encouraged many agencies to serve their APIs on our platform. Products such as APEX increase visibility of resources shared by agencies, fostering a culture of collaboration and co-creation.

BUILDING PLATFORMS TO SIMPLIFY DEVELOPMENT

By offering a platform to serve and manage APIs out-ofthe- box, APEX has removed the need for agencies to develop and maintain such technology as part of their own projects. Products such as APEX which offer common services can greatly reduce development effort and cost for agencies.

WORK IN AN AGILE MANNER

The vision behind APEX to provide a government-wide API platform was a big one. However, the team successfully adopted the Agile methodology to break down a large problem into incrementally deliverable parts. The team was able to focus on releasing a minimal viable product early for testing. This drove a virtuous cycle of test, iterate and extend which allowed the team to release regular updates with enhanced features, bug fixes and the latest security patches.

VALUE THE USER

Early iterations of the APEX user portal were unusable to many of our early users. They did not find using the portal intuitive and found many missing workflows that prevented it from being a self-service hub for browsing and subscribing to APIs. Listening to feedback from users allowed the team to refine the portal to its current user-friendly and accessible state.

APEX Introduction Video can be downloaded here: https://drive.google.com/file/d/0B84- 8GIFcQYKNVdmVVFMWHRVeWs/view?usp=sharing