Sergey Nivens - Fotolia
Why API-first software development leads to shiny API people
There is a fundamental difference between using application programming interfaces for integration and having an API strategy for reuse. We look at how APIs can make digital initiatives shine
An application programming interface (API) enables software developers to gain access to other pieces of code via a single programmatic connection and has been a fundamental time-saver in software development. As the mantra goes, “Don’t reinvent the wheel.” So if a piece of code or an algorithm has already been coded, and there is an API available to access it, why not use this instead of writing something similar from scratch?
Not every company wants to become a software company. But experts believe that an API-first approach to software development, combined with a portal that publishes APIs available to developers and offers a level of governance, can help businesses polish their software development efforts.
Satish Maram, director of API and integration at Astrazeneca, said: “Fundamentally, an API enables you to build once and use multiple times.” According to Maram, a good candidate for a reusable API occurs when there is a need to integrate two systems and this integration is likely to be used in more than one place.
Such reuse is becoming a key part of the IT strategy at the Department for Work and Pensions (DWP). Jacqui Leggetter, head of integration at DWP, said: “Building services for reuse is our strategic objective.”
During a panel discussion at the recent MuleSoft Connect 2019 conference at London’s Excel, Leggetter, Maram and fellow panellist Ben Turner, CTO at Legal & General, general insurance, were asked for their views on the benefits of APIs, and best practices in building them for reuse.
The panel members agreed that the concept of an API is something business will often find hard to fathom. Instead, the discussion should concern business services that are made available through APIs, as Turner explained. “I don’t talk about APIs,” he said. “We talk about services the business wants to consume, and try to find everyday scenarios to explain them.”
During the first year of using APIs, Leggetter said the DWP team began changing the way it named new API calls. The old APIs were previously numbers-based. “Through the first year on the team’s API journey, we stopped talking about APIs as numbers,” she said. “Every API should start with a verb.”According to Leggetter, this changed the mindset associated with APIs.
Business change
Embarking on a programme to develop new APIs that can be used throughout the business requires a change in attitude to IT-business alignment. While application development teams may be accustomed to writing software for a specific business function, an API-based approach to software development requires the team to think about how the code they build can be reused.
Before 2016, Legal & General ran software projects that relied on point-to-point connections, said Turner. “The idea was to build it once, then it’s done. We needed to change and disrupt the mindset, both in business and in IT.”
Similarly, Leggetter said the DWP team “had a lightbulb moment” when it started work on a project for the Scottish government that had many similarities to a microservice it had previously developed for HM Revenue & Customs (HMRC). “The service we built for the HMRC wasn’t reusable because we exposed five things in a single API,” she said.
Leggetter said the team realised it would get better reuse if the microservices it developed were more granular. So for its next project – a free NHS prescription entitlement check service that had similarities with the HMRC microservice – the team looked at developing granular APIs. “We split the microservice into separate APIs,” said Leggetter.
The panellists shared their experiences of how their teams began seeing productivity benefits once an API-based approach had been used to build a project. At Astrazeneca, Maram said the first project his team built using an API-based approach actually required less work than traditional point-to-point integration – but the real value of APIs came in the second project. “We assembled composable Lego blocks [of software] so we only needed to build half as much during the second project,” he said.
Agriculture and environment products company Yara International is an example of an organisation starting out on its API journey. Yara has begun using MuleSoft’s AnyPoint API management software as part of a wider initiative to link IT closer to the business and develop software more quickly.
Read more about API management
- Over the next few years, the existing access to UCAS’s systems will be switched off. Universities will need to use new APIs, powered by MuleSoft.
- IT orgs that face a hybrid mix of apps and data sets can turn to iPaaS for integration – without the overhead of more software to manage. And there’s more than one kind of iPaaS.
Explaining the drivers behind using API management, Patrick De Sarrazin, head of API and integration at Yara, said: “We don’t have the luxury of being able to discuss something and then work on it for a year. If you are thinking about something, then someone else has probably already begun working on it.”
Three years ago, Yara’s IT went through a transformation to become closer to the business and began an initiative called the Yara API economy. De Sarrazin explained: “We wanted a shift-left philosophy on integration. We wanted to empower our programmers to do more and do it in an organised way.”
According to De Sarrazin, the approach Yara has taken enables programmers to work with what he calls a “bimodal model”. This so-called “shift-left” approach means Yara enables its programmers to solve problems in their own way and for their ideas to be published in a way that everyone can benefit from.
Ross Mason, founder of MuleSoft, believes software developers struggle to understand the benefits of writing code that is reusable through the use of published APIs. In his experience, developers find it hard to make the connection between the software they build and the outcomes the company is looking for.
“Developers are not really thinking about the value,” he said. “It’s like delivering an IT project that has no uses outside of the domain it was designed for, versus one that adds value to one or more constituents in the organisation. We have to start helping developers think about the value they provide in the software they build.”
In many ways, Mason and the other people Computer Weekly spoke to believe IT needs to push back from simply delivering what the business wants. Instead, software developers need to deliver services available through published APIs that can be reused over and over again, helping the business to bring new digitally powered products to market more quickly.
