Open Banking PTBR

ensure performance and uptime is monitored, and basic security provisions including throttling overuse where resources can be more efficiently called and to prevent malicious targeting. When an API management solution is in place, an enterprise can focus on reorienting their architecture towards an API/microservices approach. This may be possible though a "lift and shift" move. In such an approach, existing services (SOAP) have an API bolted on and are then made available as new reusable REST components that can be used to speed up product development without wholesale changing the underlying legacy infrastructure. Others are taking a "build and replace" approach whereby when an element of the monolith needs to be carved out to be updated, that is done first to create an API and, over time, as the monolith is carved out more and more, you look around and suddenly you have a microservices network rather than a single code base. API Management services are an essential part of the banking stack. Axway banking customers we spoke to as part of this research have been particularly impressed with Axway's capabilities in assisting them with the API management solution. "We are usually a build kind of company, so at first, our developers were keen to build an API gateway and management solution themselves," said one banking executive. "So what Axway gave us was a solution that is easier to implement quickly, that enables us to use less resources on developing and maintaining that solution. It was quicker and cheaper than building, and gave us a lot more functionality." Interviews with banking executives and respondents to the Banking APIs State of the Market survey suggest that this process is now about halfway through for many banks. It is incredibly complex, and often requires upwards of 500 internal services to be redesigned as REST APIs. Meanwhile, the Strategy-with-APIs approach is much more about how do you design an architecture that will enable a future platform and ecosystem to emerge, as that is the strategy play that will be required by banks to ward off startups and tech giants enveloping market share. Creating an IT architecture that will support a Strategy- with-APIs business approach means being able to split datasets and business functionalities so that core business assets and infrastructure are kept close to the company, while distribution, content and customer-facing capabilities are provided in layers that may be opened up to a wider selection of industry players. This is what it would look like: Process APIs Experience APIs APIs Strategy Platform Economy Core APIs Distribution Infrastructure Customer Experience Assets Core APIs here exist between infrastructure and assets. They are mostly for traditional IT purposes, and speed up product development and internal data sharing across business units and geographies. Jeff Bezos' infamous email arguing for all new business components to be built as APIs is a good example of the core API approach. Many of those weren't intended for partner or external use, but aimed at allowing internal teams to reuse code blocks when building new products and features. Product management still very much comes into play here: internal teams need great documentation and intranet resources that allow discoverability of the APIs build in other business unit teams. Interviews with banking executives suggest that it may be politics that prevents this from occurring smoothly within banks. Almost half of survey respondents (44%) indicated they have a central API team, while 29% have an API center of excellence. Often these teams are charged with writing the API standards and style guides for a bank, and are available to work with individual lines of business on the APIs they develop. 08 State of the Market report 2018

• Cover