A Playbook for Enterprise API Adoption – Part 2

(Editor’s Note: What follows is Part 2. Part 1 appeared on Wednesday at https://www.architectureandgovernance.com/uncategorized/a-playbook-for-enterprise-api-adoption-part-1/.)

API Monetization:  The four API Monetization models are,

  • Fee-based: The end user pays as per the API usage. The types of fee-based rules are,
    • Transaction fees: These types of fees can be by API transactions or another custom attribute that we designate
    • Transaction volume: The end user is charged based on the volume of API transactions
  • Charging: This model covers subscription type, advanced and pro-rated models.
    • Subscription fees: The end user is charged the recurring fee that is charged on an ongoing basis at a preset frequency
    • Advance or arrears: For advance, fees are charged upfront at the beginning of the billing period; for arrears, they are charged at the end of the billing period
    • Pro-rated or full amount: The fee can be pro-rated based on the end user plan purchase and termination dates
  • Revenue share: It covers fixed, flexible and hybrid models.
    • Fixed: In the model, sharing of a fixed percentage of the net or gross revenue generated in each sale made via the API with the end consumers is done
    • Flexible: Sharing a variable percentage of the net or gross revenue generated in each API-driven sale with the end consumer is done.  The percentage could be a function of total revenue generated across API transactions over a specific time
    • Hybrid (flat fee plus fixed or flexible): Charging a flat fee per API transaction and also sharing a fixed or variable revenue share percentage of the net or gross revenue generated in each sale with the end consumer is done
  • Freemium: offer an initial set of usage for free. Below are the types:
    • Duration: Initially, set a free period over which the end users will not be charged. The fee-based plan kicks in at the end of this initial free duration.
    • Quantity:  Set a free quantity for which the end user will not be charged.
    • Hybrid: Set duration and quantity elements. The end user will start being charged once the first threshold is crossed

API Monitoring: The monitoring of API addresses the following steps,

  • Number of subscriptions per API (across all versions of an API)
  • Number of API calls being made per API (across all versions of an API)
  • The subscribers who did the last 10 API invocations and the APIs/versions they invoked
  • Usage of an API and from which resource path (per API version)
  • Number of times a user has accessed an API
  • The number of API invocations that failed to reach the endpoint per API per user
  • API usage per application
  • Users who make the most API invocations, per application
  • API usage from resource path, per application

f). API Governance & Collaboration

A typical API Governance Model consists of API Steering Committee, Architecture Board, an API Governance team, and API Implementation Team.

Fig 3 API Governance Model

                             Fig 3:  Enterprise API Governance Model

API Steering Committee: Responsible for Digital Strategy and API program with Business Objectives. The following are the activities to be performed by the digital leadership team,

  • Approvals & Sign-off
  • Participating & Providing inputs during business & technical workshops
  • Knowledge sharing / Guidance on business & technologies
  • Identify & bring in the SMEs for Governance & oversight

Architecture Board:  It consists of EARB Lead, Lead Enterprise Architect, and Lead Business Architect.

  • Lead Enterprise Architect is responsible for API Strategy definition and governance of the Digital program that includes API. Defines the API reference architecture.
  • Lead Business Architect is responsible for providing the strategy for the requirement of API for various LOBs across the Enterprise.
  • EARB Lead approves the Enterprise API adoption strategy and reference architecture.

API Governance Team: It consists of the API COE Lead, digital architect, API solution architect, and API platform specialist.

  • Digital Architect: Responsible for realizing the API Strategy definition and governance of the Digital program that includes API (Enterprise Architect, Chief Architect)
  • API COE Lead: Responsible for Technology and Delivery of the Digital Initiatives, including APIs.
  • API Solution Architect: Architects/Designer who works with domain teams to design APIs. The review of the API design is done by Solution architects. They check for,
    • Functional validity of the API and its contract
    • Checklist on API guidelines and standards. A violation of policy like non-usage of the internal primary key is caught
    • Security aspects and PCI, SOX, and other compliance standards
    • Ensure the traffic policy as is per volume requirements

The following are the activities to be performed by the API Governance team,

  • Workshops with stakeholders to understand Strategy & Governance needs
  • Enterprise API Strategy & Vision development
  • API discovery sessions
  • API Governance setup – Planning, Design & Development & Runtime Governance
  • Drive Standardization – API Taxonomy, Open API Adoption, Policy Setup
  • Evangelization Programs, Boot camps
  • API Design Workshops
  • API Promotion Events, Nurture API Community
  • Innovation – Conducting Hackathons, Integrating Partner Ecosystem

API Implementation Team: It consists of an API product manager, scrum master, API developer, and operations team.

  • API Product Owner: The business team responsible for conceptualizing and defining APIs
  • Business Analyst: Responsible for analyzing various LOBs requirements and preparing the API mapping specifications
  • API Developer: Team members in Domain teams trained on the API platform to develop APIs. The developer,
    • Checks if a similar API and contract definition is not already existing in the portal
    • Follows Guidelines and strategy defined
    • Models the APIs based on the sample Production API in the matching category, in terms of policy definition
    • Ensures that the default policies are adequate for API needs
    • Takes an exception to create a new policy or suggests a change to the base policy, if the base policies do not match the expected requirement of the API
  • Infrastructure Lead: Leader responsible for the upkeep of the API platform (Platform admin, Infra. Lead, API Platform Specialist).
  • Release and Build Team: It consists of the API support team, and release/build manager. Responsible for day-to-day operations and production support of the API platform.
  • API Tester: Responsible for testing and validating the APIs to assure the Quality.
  • Security Team: Responsible for Sign offs on security aspects of API Platform. The security team can choose to do a sampling of the APIs for security audit purposes.

 

The following are the activities to be performed by the API implementation team,

  • Scrum Management
  • Reference Architecture, API Platform, and Framework Setup
  • Validate design and support development
  • API / services built on the API Platform
  • System Integration Testing & UAT Support for API
  • Support Deployment for APIs developed for various scrums

g). API Effectiveness

This phase helps us to measure the usage of APIs by the consuming applications. API owners develop the usage analytics of the API across the enterprise.  Higher usage of the API indicates the capacity increase horizontally or redesign of API implementation. Verification of the API error logs for any issues concerning API failures and reasons why failures could have happened need to be done during this phase.

Benefits of API

The following are the benefits of API usage across enterprise,

  • Revenue: Charging developers for access to the API, facilitating the in-house creation of pay-to-play applications, or enabling e-commerce
  • Reach: Support new customers or increase the value of current customers by offering existing services via new platforms and devices
  • Engagement: To market products and services, without necessarily becoming involved in how these offerings are delivered.
  • Better UX: To optimize offerings by presenting corresponding add-on products and services. API Technologies provides data that Enterprises can use to deliver custom-made experiences
  • Better efficiency: Automate numerous processes while developing and managing a product
  • Enabling Innovation: To provide business agility, and develop new systems, offerings, and strategies from the inside because they reduce technical barriers to innovation.

Conclusion

Today, majority of the Enterprises are undergoing digital transformation. As part of application modernization, Enterprises are adopting the latest technologies to make informed decisions and achieve cost efficiency. API adoption plays a major role and helps in Enterprise transformation.

APIs have become omnipresent, and they are used in providing solutions for internal applications of an Enterprise, public services, and partner integration.

APIs can be accessed locally or over the internet and they can be designed to accept inputs from any number of programming languages and protocols. Computing becomes more flexible, more accessible, and more efficient with the usage of API.

API governance reduces costs and improves API quality. Its benefits come from aligning contributors, establishing efficient processes, and promoting consistency, and must involve, at least, the following topics,

  • Providing guidelines ahead of time
  • Review APIs early in the design process
  • Automating as much of the governance process as possible

Also, the adoption of API shortens time-to-market and improves quality. API adoption optimizes business performance and provides better efficiency. With APIs, businesses can automate numerous processes while developing and managing a product. That way, businesses can make decisions quickly and achieve better outcomes.

Acknowledgments

The author would like to thank Santosh Shinde of BTIS, Enterprise Architecture division of HCL Technologies Ltd for giving the required time and support in many ways in bringing this article as part of Architecture Practice efforts.

About Authors

Dr. Gopala Krishna Behara is an Enterprise Architect in the BTIS Enterprise Architecture division of HCL Technologies Ltd. He has a total of 27 years of IT experience. Reached at gopalakrishna.behara@gmail.com 

Tirumala Khandrika is an Enterprise Architect at Wipro Technologies with over all experience of 22 years in IT industry contributed to this article. Can be reached at ktrbsarma@gmail.com.

Disclaimer

The views expressed in this article/presentation are that of the authors and HCL does not subscribe to the substance, veracity, or truthfulness of the said opinion.