Over the last decade we’ve witnessed the advent of the ‘Platform Economy’ - Businesses like Uber Taxis and Airbnb that have built massive global success not through owning their own assets in these sectors, but through building and aggregating digital marketplaces of self-employed vendors and landlords.
At the heart of these business models are Cloud technologies that enable rapid, massive scaling, and APIs, for enabling an ecosystem of partners to build upon that core platform and create new service innovations. This is why Gartner also describes it as ‘The API Economy’.
Industry API programs
We’re now seeing initiatives to apply and tailor these concepts to specific industries, in particular Banking and Government.
Open Banking refers to “the use of open APIs that enable third-party developers to build applications and services around the financial institution.” Through a set of industry-agreed specifications banks like Lloyds, Nordea, Starling and many others are cultivating developer ecosystems that integrate with their core account services to add value through apps for functions like personal finance management.
‘Government as a Platform’ (GaaP) refers to the trend taking shape in the public sector, coined by Tim O’Reilly in this presentation and documented it in this book section, describing how traditional IT for government should become more like Facebook, Twitter and the other Internet pioneers who have been harnessing the evolution of the Cloud to become ‘platforms’, doing so for government would enable a shared infrastructure that enables more rapid digital transformations.
In his Code for America video Tom Loosemore describes the background and philosophy in making it a central design model for GDS, the UK Government’s digital team, and their GDS blog provides ongoing updates on adoption progress, such as how it is helping meet the challenges posed by the Coronovius.
API Development Best Practices
Successfully building and deploying API-integrated apps comes with a number of challenges that 2i expertise and methodology can help address.
For example in his presentation to the APIdays Paris conference, Chris Michael the CTO of the Open Banking organization responsible for the standards, noted that key success factors include the availability and performance of the APIs, factors that many banks were struggling with.
Considerable variance in performance was noted, with API response times ranging from 1-2 seconds for some banks, through to the interesting observation that the Cloud, mobile-only challenger banks were working at a much faster 10-20 millisecs. Chris noted that for informational only services, like simple account aggregators, this is acceptable, but as services mature and take on more demanding tasks like digital payments, 100% availability is essential.
2i’s expertise and key vendor relationships can be applied to great effect here. We’re working with organisations like the Scottish Government, helping them to build new digital services that make use of API integrations with the DWP, to enable eligibility checks for social services.
This PublicTechnology interview explores in detail how the DWP are working with APIs. For example when the NHS undertakes a real-time check for prescription charge exemption they call the DWP passport benefit API which validates the enquiry. They also perform this check for the Department for Education for free school meals entitlement and for local authorities for the disabled Blue Badge award.
Serverless API Testing
2i offers expertise with a wide range of testing tools that can be applied for different needs. For API testing we use Postman, a collaboration platform for API development, with features that simplify each step of building an API and streamline collaboration so you can create better APIs faster.
In their blog ‘Don’t get TechCrunched: performance testing for your HTTP APIs’ they provide a detailed walk through of how their technology can be utilized for API testing, including a recipe for implementing it on AWS Lambda serverless computing.
As they describe in this Internet age a simple mention on a site like TechCrunch could drive a huge spike of traffic to your website and you need to know it is prepared to cope, and they share a comprehensive guide to how best to achieve this.
They explain how to get started with test automation, establishing a process for functional and integration testing and then moving on to look at performance testing to gain a deeper understanding about the stability, reliability, and availability of your platform.
This covers an analysis of performance testing, how it is broken down into stress testing, to determine the system’s ability to handle a heavier than normal workload, endurance testing, to determine the system’s ability to handle a specified workload for a prolonged period of time, and load testing, subjecting an API to a workload that approaches and possibly exceeds the limits of its specifications.
They also document how to define API performance metrics so that you can structure SLAs to suit your business needs, how to assign the work responsibility across your team and importantly, how to integrate it into your Continuous Integration workflow.
This emphasises that testing shouldn’t be an isolated, last step in the development process, but rather be an ongoing, integral function, so that you can identify bottlenecks and improve the stability of your application before it is released to production, catching issues and errors in the early stages when the cost of debugging is the lowest.
AssureRMF
2i’s expertise and consulting services can help organizations with the full spectrum of these recommendations and practices, including implementation of tools like Postman and the overall team and process transformation required to integrate its use into a DevOps lifecycle.
Our AssureRMF framework offers an engagement that maps the flow of your development, identifying process bottlenecks and constraints that can be addressed through our mix of coaching, augmentation staff services and the application of the right tools like Postman where required.