A streamlined API process is important, especially when it comes to the fintech industry, because well-built and consistent APIs attract business. If the integration cost is too high and software developers need to learn the models of each API, they will prioritize a competing bank.
Engineering teams in a federated model often make their own decisions on how to build APIs. When there’s no consistent process—when each API is built to a single-use case—each team has to learn each different API documentation. Each API might also use different security technology, such as Mutual Transport Layer Security (mTLS) or JSON Web Tokens (JWTs). The IT security team then has to cover all of these potential threat vectors.
To make matters more complicated, new regulations on data or services available through APIs could be introduced—such as data privacy and AI ethics regulations and the new open banking standards in Europe—which each API will then be assessed against.
All of these challenges affect a company’s ability to build an ecosystem of third-party providers building with their APIs. They also make it difficult for software engineers to speed up feature and product development. Companies in only a few sectors—the Buy Now Pay Later, international remittance transfer, and e-commerce payment—offer consistent, well-designed, standardized APIs.
A centralized team solution?
The solution to these structural problems could be a centralized team that builds APIs for all business lines. But this causes another problem: it slows down new API development.
Models such as Team Topologies are influencing software design and API teams. In this model, a centralized platform team helps build standard tools, including style guides and an internal developer portal such as the open source backstage.io. With access to resources that support consistent API design, engineering teams can work at pace to create and deploy new APIs. The Team Topologies model also proposes creating an “enabling team”—made up of engineers from across the enterprise or from within the stream-aligned team and platform team—to facilitate the use of the style guide and other governance processes while building new APIs.
Adopting API governance practices
API governance offers a set of tools to centralize the building of APIs. Drawing on centralized resources, engineering teams can create APIs using a consistent design and set of standards that match their priorities. Teams build APIs as they see fit, so each business or product team can remain autonomous.
Establishing governance processes can take some work. But after these processes are documented and defined, they can be automated—incorporated into CI/CD pipelines for example. After the process is set up, you can monitor governance through observability tools. This reduces governance oversight and allows innovation at pace, without compromising quality or robust API design. Security and regulatory requirements will be embedded into API designs. It also helps a financial services institution’s API ecosystem grow, creating new customer acquisition channels and new revenue streams.
Download the API governance scorecard with the 11 processes to put in place. Score your maturity using our checklist. Learn what these processes do, why they’re important, and how to measure them.
The views expressed on this blog are those of the author and do not necessarily reflect the views of New Relic. Any solutions offered by the author are environment-specific and not part of the commercial solutions or support offered by New Relic. Please join us exclusively at the Explorers Hub (discuss.newrelic.com) for questions and support related to this blog post. This blog may contain links to content on third-party sites. By providing such links, New Relic does not adopt, guarantee, approve or endorse the information, views or products available on such sites.