A rapid API roll out with a robust funding approach [2/3]
last blog, I also highlighted the essential areas of consideration for the organizations to start their API journey. In this blog, I have elaborated the aspects of governance structure / funding models, and technology aspects.
SOA and API governance: Both drive re-usability
What is the difference between service-oriented architecture (SOA) governance and API governance? - A question that is asked most frequently. Both drive re-usability but sharing the required level of control is different. Since SOA is all about business reusability, the governance structure put in place has strict key performance indicators (KPIs) on reuse. APIs on the other hand are governed by speed and are typically built to extend business reach. The governance here is still promoting reuse, but when a decision between speed and reuse is to be made, typically speed wins the debate. Also in many cases, internal developers start using APIs and then they are exposed to external developers. By that very nature of adoption, it is possible to start with a lightweight governance and then move towards a more comprehensive governance model. But in all cases, speed is prime driver behind API-fication and the governance model will remain lightweight compared to a SOA governance model.
When you start building an API, you need to create a core team. Typically, the core team that decides and develops APIs includes:
- Product managers - APIs need product managers who periodically collect requirements from businesses and provide to the technical team that builds APIs. They also monitor how many calls have been made to the APIs and who are the consumers of the APIs. They also decide when to enhance or decommission the APIs
- Technical team / engineering team - Defines the granularity , technical design, products, and work closely with the product managers to enhance functionality
- Operations team - Primarily ensures when the APIs are up and running, alerts teams for any downgrade in performance, and looks at the overall well-being of the APIs
The core team is set up by a steering committee with the mandate to fund the APIs and provide overall directions. External teams that need to support the core team will also include a legal team that can come up with legal clauses for exposing the APIs to external developers. For monetization, integration team needs to incorporate the APIs with the back-end core systems and the owners of the applications will expose the APIs. On the customers' side, where there are many large legacy applications, the legacy application owner needs to work very closely with the core team and define the APIs that will be exposed. In fact, for banks and insurers with large legacy footprint, these teams can often be part of the core team.
Staying in competition with funding models
For funding, we need to understand two points:
- How APIs will be monetized to make the external consumers pay
- Who will pay for building the initial platform and APIs
For the monetization of the APIs, there are multiple business models. They include the APIs that are offered for free, premium, developer pays, developer gets paid, and most importantly, where there is an indirect benefit to the organization. In my experience, telcos / media companies are way ahead in terms of monetizing the APIs. News feeds and videos syndication APIs are common in telcos and media companies.
However, other segments, especially financial sector is exposing APIs for indirect benefits they get in terms of better brand recall, competitive advantages, or just to stay in competition. Most banks have now exposed their usual services on mobile platform to remain in competition. Among financial organizations, many payment providers offer their payment APIs for consumption against one of the commercial models.
Who will pay for building the APIs if the APIs are not immediately monetized? In one of the banks, I was speaking to the core team in which legacy application owner was also present. The team wanted to know whether they should wait for the business to identify the APIs for them to build. Of course, this will delay the roll out and frustrate the business. On the other hand, if they build a platform and be ready with some of the common APIs, who will pay the bill? Though there is no easy answer to this question, here is the model that I have seen work well before:
- Collaborate with the CIO (Chief Information Officer) / Chief Digital Officer (CDO) to make a business case for a seed funding to build the initial platform with the core services
- Create an internal team that evangelizes APIs with the line of business (LOB) that is most likely to build the APIs. In fact, build few APIs for these LOBs for free and charge them when they start using the APIs
- If the internal evangelizing is proceeding well, LOBs generally come on board and they can share the cost of running the platform
- If you can monetize the APIs, you can start paying for subsequent enhancements
The advantage of this approach is that it is far easier to roll out APIs as the basic building blocks are ready in hand.
Typically, APIs are identified through top-down approach. However, in most cases, the programs on the z/OS do not offer the capability that an API design demands and the code needs to be refactored. In many cases, the programs include both the business and the screen logic, and there is no separation between them. In such cases, the code is to be refactored to separate out the logic so that it can be encapsulated. In my experience, this work requires more effort than required to expose the APIs on the z/OS platform.
For exposing APIs on z/OS, there are multiple technologies available. Traditionally, most organizations having large mainframe footprints also have CTG or CICS TS available with the z/OS systems. These technologies help in exposing APIs but these have the following disadvantages:
- They operate on the general processor and therefore are more expensive when they land multiple calls.
- These technologies do not implement entire representational state transfer (REST) APIs. They support POST (one of many request methods supported by the HTTP protocol used by the World Wide Web) methods only. This is not a good architectural principle.
IBM has launched z/OS connect that operates on the z integrated information processor (zIIP) and has the following benefits:
- Provides API description using swagger specification
- Offers an integrated development environment (IDE) to map the common business-oriented language (COBOL) copybooks fields to the JSON request / response fields
Together with a strong governance and a robust funding approach, the right technology will help in rapid API roll out.