Nordic APIs Presents a Case Study of Maersk APIs

Over at the Nordic APIs blog, Thomas Bush has written a case study investigating the Maersk API and the path of discovery that led to their current strategy of leaning into web APIs, as well as exploring their current API management tactics.

This case study is based on a talk given by Dave Holliday (Product Owner of Maersk’s API Management Platform) at the 2019 Nordic APIs Summit. This talk is also available to watch on Youtube.

Halliday’s talk begins with an overview of the impact that Digital Transformation has at Maersk, using their status quo for supply-chain tracking: the EDI 315 Status Details (Ocean) document: “The EDI 315 Status Details (Ocean) document is a message generated every time a Container’s transport status changes, such as when it’s loaded onto or discharged from a shipping vessel. These messages are then distributed using transfer protocols like FTP, SFTP, and AS2.”

The messages are problematic: they are costly to produce and difficult to digest. Dave presents a solution, suggesting the presentation of the data as a JSON object. This presentation makes the messages cheaper to produce and simple to consume.

Looking back over the Maersk development journey, Dave highlights the five primary mistakes visible with hindsight: no Developer Portal, interoperability standards, or API keys, limited functionality, and excessive firewalling.

Going forward, he sees API management as a crucial area, beginning with an internal management platform. In order to meet company goals, he lays out his four-point strategy:

  • Discovery: The platform should help to avoid duplication and enhance the reuse of APIs. This is achieved with easy discovery of existing APIs.
  • Support: The platform should track who built each API, where the codebase is kept, what Stack was used, how it is tested, and how support for the API is provided.
  • Proxies: The platform should enable seamless deployment of API proxies, in a playground and through higher environments.
  • Data: The platform should enable data to be collected, monitored, and analyzed for business purposes. For example, 404 errors in the schedules API (Schedule not found.) could help to identify new routes for Maersk to service.

The external management platform at Maersk will include discovery (to match customers with the right API), testing (easily run by customers), and the possibility for monetizing certain APIs. 

The final thoughts for the case study focus attention on both mistakes made along the way, and plotting a future course to success: “With both internal and external flavors, Dave’s current API management strategy is designed to ensure APIs are as self-service as possible and create as few headaches as possible!"

Be sure to read the next API Management article: WSO2 API Manager, API Microgateway Add Support for AWS Lambda and gRPC

Original Article

APIs at Maersk: A Case Study