Issue link: https://go.axway.com/i/1137349
Feedback Feedback Feedback Cost Value Risk Risk Risk Risk "We have a hybrid approach," explained one banking executive. "We have a centralized group that provides delivery support functions: a set of libraries that implement cross cutting concerns for all APIs, token validation, logging and metrics. The libraries are then picked up by the line of business that is delivering the API services for use. They write their own code, they use these libraries, and they deploy in a mostly standardized way. There is about 70-80% of business units using this methodology and one or two lines of business that are outliers and doing it their own way." This experience was fairly common across banks interviewed. Process and Business APIs sit at the assets and distribution layers of an industry vertical. These are mostly released as partner APIs and enable automation and speed of transaction between a business and its suppliers, partners, agents, resellers, and other key relationships. Experience APIs then sit on the top of the industry vertical and exist between the distribution and customer layers. These can be very narrow APIs, with very specific use cases, such as an API to create a chatbot, or an API facade that makes common business processes available for a niche market. These are the APIs that could be opened to third parties. This sort of structure for API design would mean a bank would become much closer to being able to seed an ecosystem. Core and business/process APIs are protected while third parties are encouraged to create new products and services using an enterprise's experience API layer. Startups were going to start at this point anyway, so the benefit of providing experience APIs is to enable a closer watch over how and what those startups are building. As discussed above, these startup speedboats can zip through the financial services industry waters much faster; but by standing on the deck of the enterprise ship, banks can keep an eye on where they go, and how they get there. A bank could validate new product features and see what sort of customer engagement strategies gain traction. Because an API management solution is in place as part of the architecture, enterprises remain in control: they can define the reasons why third parties can make API calls, they can manage scopes to ensure authorizations remain within agreed boundaries, and can measure uptake by monitoring what sort of apps and domains are increasing in their number of calls. An API management solution gives a bank the who, what, where, how much and how metrics of an API, so it is easy to measure the value that the API is creating. This approach also reduces risk for the bank. Incumbents need 18 months to 2 years for product development lifecycle because they are currently weighed down with legacy systems (on all fronts: IT infrastructure, business organization, and internal culture). That makes major releases highly risky if they do not have strong market fit. By releasing experiential APIs to third parties working in niche sectors, that risk is reduced so that it is containable and more easily monitored. The feedback loops for large banks and banking groups, which had the slow steering momentum of a large ship, shortens, as small experiments are made by third parties. 09 The RISK STRaTegy