API Funding Model

Purpose

APIs represent significant enterprise assets that provide important capabilities and benefits like re-usability, flexibility, agility and decreased time to market. These assets, like applications, incur costs to implement, operate and maintain. The concept of API ownership is key to address issues and challenges. A well-defined approach for ownership will provide decision making accountability at the appropriate level.?The purpose of this article?is to identify the right level of API ownership model for the adopting organisation along with other key Concepts.

API Domain Ownership

API ownership establishes an unambiguous, known point of overall accountability for API throughout its entire life-cycle, from initial identification, sponsorship and funding, development and deployment, subscription and operation, support, enhancement and versioning, and eventually retirement.

For every Adopting Organisation, in the Center of Practice (CoP), it’s often decided to have API Product Ownership which is a joint team formed by ‘Business Owner’, ‘Business Systems Management’ and ‘Enterprise Architecture’ teams.

In this ownership model, Business Owners will own the API and provide sponsorship and funding. Enterprise Architect team will provide technical management for API (Develop and Manage)

Business Domain and API Ownership Scope

• In general API ownership will be structured using business domain model that reflects an enterprise’s business architecture.
• This ensures that there is a close relationship between deep knowledge of a business domain, its purpose, goals and drivers, and API/Services that automate functions associated with the domain that are reusable both within that domain and when shared with others.
• Each of these business domains is further subdivided into “functional areas”, each representing a subset of the domain’s overall functional capabilities.
• However, in some organisation which just started to build the API community, the API owner might then be owned by the technical team, mainly with the enterprise architect team.

API Domain Owner Responsibility

The API Domain Ownership (ADO) leverages a deep understanding of business needs and API/Services (existing and proposed, new and or versions) to make business decisions about the API/Services/APIs in their domain

• Authorising the creation of API/Service or API
• Authorising access to API/Service or API through subscription
• Addressing Funding issues associated with the API/Service (i.e. subscription cost, maintenance cost, model, build, deploy, retire cost)
• Delegate the development and maintenance of the API/Service to the corresponding teams.
• Committing to the exposure scope of API/Service (enterprise, sector, LOB, project)
• Communicating status and capabilities of API/Services within domain
• Requirements identification and tracking
• Subject matter expertise
• Identification of API/Services uniquely within the business domain
• Consult on effective use of domain API/Services by all business areas
• Specification of API/Service characteristics
• Quality of API/Service objectives etc.
• Manage API/Service versions
• Participate in funding decisions.

API or Service Domain Ownership Model Process

The process owner is responsible for executing all the steps of this process.?In general, the process will be executed by a team at a minimum comprised of the process owner, subject matter experts representing the major functional areas and lines of business and an Enterprise or API/API/Service architect.?

?Input Impacted to API Ownership Model

• Initial Creation or Request for New or Restructured Domains

This input is associated with the Entry Point where the API/Service Ownership Domain Model does not yet exist, or where a request has been made to significantly restructure the domains.?Restructuring could occur for a variety of reasons:

• A new Line of Business (LOB) has been added to the organisation
• An existing domain has become too large to manage and is being split into smaller manageable domains
• Several domains have complementary function and can be better managed by consolidating into a single domain.
• Change of Ownership
• This input is associated with the entry point where the process is being executed to change the ownership of existing domains.

?

API Ownership Model task

Task 1 – Define API/Service Domain Structure and Scope

• Candidate API/Service domains are selected from the available input.?As noted, API/Service domains can be classified as Technical, Functional, or Application.
• This process will focus on the functional domains.?These domains relate directly to business domains, or the logical grouping of business functions.?Clearly it would be possible to define an application domain that corresponds to an application package that is installed in the organisation.?However, defining a business by the installed applications can create significant problems.?Many application packages today, such as SAP, cover many functional areas within the enterprise and the functional boundaries may be very significant if a decision is made to change application providers or to evaluate other packages that may better API/Service a subset of the functions in the existing package.?If the focus is placed on the functional domains, then functional domains can be allocated to application domains and if desirable, a domain owner can be allocated to cover the application domain.?This allows very well-defined functional boundaries to be defined, avoiding the problems mentioned above.
• Functional domain candidates can be extracted from Business and Industry models.?These models typically provide a view that logically groups business function and for which similar skills and expertise are required.

?Task 2 – Map Domains and Determine Overlap

Once the domains have been selected, an exercise to map and define the exact boundaries of each domain must be performed.?Any and all overlaps should be resolved.?It is possible for an enterprise to allow overlaps that for political purposes need to exist, but this will cause problems for API/Service reuse and should not be encouraged.

?

Task 3 – Determine Impacts on Existing Domains or Architecture

This task examines the proposed domains to determine if there is any anticipated impact to existing domains or to the enterprise architecture.?A checklist should be used to ensure consistency in this analysis.

Task 4 - Create candidate list

The role of domain owner should be fully defined as part of the governance mechanisms, including responsibilities.?If that role has been defined, the responsibilities of the domain owner should be used as input to creating a candidate list.?If this process is being executed prior to the finalisation of roles and responsibilities.

Task 5 – Assess and Nominate Domain Owner

From the candidate list, assess the candidate based on the responsibility defined:

• Communicating status and capabilities of API/Services within domain
• Requirements identification and tracking
• Subject matter expertise
• Identification of API/Services uniquely within the business domain
• Consult on effective use of domain API/Services by all business areas
• Specification of API/Service characteristics
• Quality of API/Service objectives etc.
• Manage API/Service versions
• Participate in funding decisions.

Task 6 - Seek the approval from Executive Steering Committee

The candidate should be ratified by all the key stakeholders, including lines of business and functional business executives.?Upon concurrence, the candidate is submitted to the Steering Committee for approval

Task 7 Appoint the Domain Owner

Task 8 Update API/Service Domain Ownership Model

Once the domains have been fully defined and owners allocated, the API/Service Domain Ownership Model must be updated to reflect the changes.

Task 9 Communicate new API/Service Domain Ownership

Formally communicate the new API/Service domain owner as per the communication plan. It is critical for all of the stakeholders to buy into the ownership of the domains to achieve API/Service reuse by all lines of business.?Therefore, business members of the enterprise in most cases should be involved in the ownership role.?An excellent mechanism for the owner role would be to form business domain ownership board and business executives

?Collaboration of API/Service Domain Owner with Other Org in Enterprise

• The API owner would typically work with the Product Advisory Board ( PAB ) to consult with and delegate responsibilities to others in the organisation.?For example, the API owner will consult with and be supported by CoP as decisions related to Service/APIs are being made.?CoP could identify an architect from it’s pool of architecture SME’s to help the owner to understand technical issues related to a Service/API.?CoP also governs the overall enterprise API/Service catalogue and collaborates with the owner to finalise decisions that impact the catalogue.?
• The owner typically delegates responsibility for API/Service implementation, operation and support to teams in the IT organisation.?The owner retains overall accountability for the Service/API, while the IT teams take on responsibility for the tasks need to implement, operate and provide runtime support for the Service/API.?
• Please refer to API government process document for more details.

?API/Service Ownership Impact on Roles, Entities and Mechanism

he ownership model represents a starting point based on a “virtual” model that delegates decisions and responsibilities to existing entities within the adopting organisation.?This approach minimises impact to the organisation and simplifies enablement of the initial API/Service Ownership Model.?The primary change for these existing roles is to adopt awareness that Service/APIs may be part of the solution, and to support an increased emphasis on finding opportunities for enterprise-wide reuse and standardisation.?

?

Product Advisory Boards ( PABs )

The Product Advisory Boards will be business domain aligned and will interface with businesses with the responsibility of products or a set of product families.

The Product Advisory Board ( PAB ) will have the following objectives to accomplish:

• Communication: Establish open lines of communication between the business and??Product management.
• Prioritisation: Enable??Product Management to listen to customers directly to ensure that product development priorities and requirements are customer driven.
• Alignment: Ensure alignment of Feature Planning releases with the strategic goals and needs of the business.
• Innovation: Provide a forum for different business unit to share perspective on strategic issues, challenges, trends, and emerging strategies.

Product Advisory Boards ( PABs ) Key Responsibilities:

• Ability to influence future product direction and to drive the product strategy with Business Stakeholder
• Owns product road-maps and have a role in funding decisions and ensuring the right Service/API/projects are selected to go forward in the SDLC API/Service development process.?
• Collaboration with throughout the product development and deployment life-cycle
• Ensure requirements with the most business value are delivered first
• Ability to re-prioritize deliverables as the business needs change
• Translate / Migrates the business vision to product roadmap/ time line / market focus
• Responsible for creating Business case/ Funding Requirement / Subsequent Business Stakeholder buy-in
• New product features/enhancement prioritisation and release scheduling by following the policy “the most important/highest value items will be delivered first” through the Feature Planning Product Advisory Group
• Understand best practices from other business units
• Forum for incorporating trends and emerging strategies into the product
• Owns budgeting process from business and Planning with the Business Stakeholder
• Communicating with business with Total Cost of Ownership ( TCO ) and business benefit
• To review and approve documentation of Business Process by Business Analyst
• To set up regular call / meeting with product manager for future work request
• To establish proper process of interaction between Business Stakeholder and technical Stakeholder process
• To interact with and coordinate with API/Service to enhance the business capability through API/Service strategy
• Post Implementation Audit and Runtime tracking of application resource utilisation and optimisation

Product Manager within PAB (Product Manager)

• The Product Manager would be delegated the responsibility of API/Service Ownership as Level 2?API/Service Domain Owner (ADO/BDO). This extends the role that Product Manager plays today for existing applications, providing business sponsorship for existing and new IT assets (e.g. applications and Service/APIs).?
• The Product Manager plays a key role in the process of establishing the business need for the actions carried out within systems to develop, operate, and enhance applications and Service/APIs.?
• To accomplish this, Product Managers will need to be oriented to the role of Service/APIs in addressing business requirements as part of solutions they propose through the API/Service COT’s prescribed process.?
• As API/Service owners the Product Managers are responsible for operation and for meeting the API/Service level agreements for all of the Service/APIs they control.??

Executive Steering Committee (ESC)

• The ESC through respective API/Service Domain Owner (ADO) acts as the API/Service Ownership Board for Level 1 API/Service Domain Owner (ADO / BDO) .?This venue is where ADOs come together to discuss enterprise-wide issues that cross business functions.
• The ESC is also an escalation path to resolve reuse and standardisation issues that cannot be resolved within systems with the help of PAB and COT.?ESC reviews Business requests and related details and delegate the request to respective Level 2 Business Domain Owner to own the respective API/Service. The Level 2 API/Service Domain Owner (ADO/BDO) works through any unsettled issues related to reuse and standardisation.
• API/Service Advisory Board (SAB) – API/Service Advisory Group (SAB) comprises of?, Technical review Board ( TRB ) and Governance review Board ( GRB ) would act as a technical resolution board for any API/Service issues within Systems.?They handle issues (i.e. deciding if certain desired functions falls within a specific domain or across domains, or disagreement on analysis of re-usability) prior to the involvement of ADOs and ESC.?
• Offices within Systems responsible for application and API/Service development (Office of Chief Architect, Project Design Authority, Project Design Team and API/Service Development Team)
• The Offices within Systems will continue to have similar responsibilities as they do now in the proposed CoP Model:
• Project Design Authority: The Project Design Authority has architectural control within projects or programs. The Project Design Authority is responsible for helping the PMO to setup Project Design Team dedicated to individual API/Service development project, guiding and reviewing solution design artefact based on the recommended reference Architecture and API/Service Design guideline and best practices. It bases its efforts on the best practices and standards set from the Office of the Chief Architect.
• Project Design Team: This team would be formed for project specific business modelling and implementing technical design which can be handed over to the API/Service Development Team.
• API/Service Development Team: Responsible for development and maintenance of the Service/APIs as directed by the sponsor. The groups that have IT responsibility (application ownership) and are the go-to people for anything pertaining to applications/IT asset
• Some of these groups map directly to business functions (business components) by virtue of supporting the applications for a business function
• CoP – will have two main responsibilities in this model:
• 1) CoP will be the API/Service owner for cross-domain Service/APIs and the API/Service framework.?In this case, CoP is the owner and takes on more of the Architecture/Design and development responsibilities than any other API/Service owner would.?
• 2) Govern the API/Service catalogue, and can recognise when reuse/share vs. specialisation issues arise, they can mediate initial discussions in that area, and can escalate to PAB/ESC any functional/technical issues that require more discussion. CoP knows "who else" needs to be at the table to discuss a candidate API/Service (i.e. when group #1 is talking about a API/Service that they may perceive as a local/silo issue, CoP may be able to tell that it is actually a broader concern and know who else needs to be involved in the discussion.??CoP can facilitate discussion across a broader range of stakeholders.?

API/Service Funding model

• During the API initial stage, the API funding model might not be critical and have not yet been defined. The current funding model from the traditional development practice shall be applied to the API.?
• ?The funding model would rely on the API owner to provide information about cost, benefits, scope for API/Services that are in the investment planning process.?The API owner could in turn collaborate with or delegate to others specific tasks to provide that information.
• The API owner would typically work with the Product Advisory Board ( PAB ) to consult with and delegate responsibilities to others in the organisation.?For example, the owner will consult with and be supported by CoP as decisions related to API/Services are being made.?CoP could identify an architect from it’s pool of architecture SME’s to help the owner to understand technical issues related to a API/Service.?CoP also governs the overall enterprise API/Service catalogue and collaborates with the owner to finalise decisions that impact the catalogue.?
• The API owner typically delegates responsibility for API/Service implementation, operation and support to teams in the IT organisation.?The owner retains overall accountability for the API/Service, while the IT teams take on responsibility for the tasks need to implement, operate and provide runtime support for the API/Service.?

API funding Model Process Flow

API Funding Model Task

Task 1 – Analyse Existing Funding Model

• Product Advisory Board and Business Domain Owner analyse the existing funding model to ensure a thorough understanding so that significant features of the existing model are not lost in the creation of a new model tailored to Specific list of APIs/Services.?This task is executed for enterprise APIs/Service implementation or for a change to the funding model.

Task 2 – Define variables and Parameters for Funding Model

• The team examines the funding model that may be available to harvest desirable characteristics.?They create a ‘To-Be’ model that is aligned to the enterprises organisation and culture and can gain acceptance across the enterprise, including the Lines of Business.?This task is executed for enterprise APIs/Service implementation or for a change to the funding model.

Task 3 – Align New Funding Model with APIs/Service Strategy

• The proposed funding model is evaluated based on the organisations APIs/Service Objectives and appropriate modifications are made to align it to the APIs/Service Objectives.?This task is executed for enterprise APIs/Service implementation or for a change to the funding model.

Task 4 – Estimate APIs/Services Total Cost of Ownership (TCO) and Usage

• The total cost of ownership of the proposed APIs/Service is estimated based upon a proven estimating methodology and in compliance to the organisations standard accounting practices.?This includes hardware, software, development, package acquisition, testing, deployment and maintenance costs of the proposed APIs/Service.
• Usage of the proposed APIs/Service, which includes issues such as Quality of APIs/Service measurements, volumes, distribution of usage over time etc. is also estimated for the TCO.
• This process requires that standard estimating methodologies are implemented in the organisation.?These methodologies should be based on common organisational historic data that provides repeatable productivity data.?In general, it is advisable, especially when introducing a new estimating methodology to perform two independent estimates using different techniques, to ensure the variance falls within the organisations acceptable limits.

Task 5 – Allocate Cost

• Costs for development, maintenance and operation are allocated based upon the organisations approved funding model.

API/Service Cost Component

• Initial Cost: - Initial cost refers to the cost involved in acquiring the tools and technologies, building shared platforms and establishing APIs/Service infrastructure, APIs/Service based development tools etc. Similarly, costs involved in defining APIs/Service Methods, Processes and developing the APIs/Service skills are also covered as part of initial cost. It also includes costs involved in defining enterprise-wide APIs/Service Strategy and APIs/Service Reference Architecture.?
• Development Cost: - Includes the cost of Development effort and other expenses required to Analyse, Architect, Design, develop and deploy the APIs/Services throughout the end-to-end life cycle.
• Operations Cost: - It refers to the costs for Operational activities. Operations cost refers to expense incurred for keeping the APIs/Services available once they are deployed in production environment. It includes costs involved to monitor the SLAs and ensure SLAs are being met. Addition of new subscribers. Retirements of APIs/Services are also Operations Cost.
• Maintenance Cost: - Maintenance cost refers to cost associated to Production support for bug fixing and minor changes in order to keep APIs/Services consumable to its existing consumers. Migration to later environments and upgrades are all examples of maintenance cost. It includes costs involved in corrective activities (not the operational activities covered in Operations Cost).
• Enhancements Cost: - Once the APIs/Services are developed and available in production, its new or existing consumers might need enhancements to APIs/Services in order to support additional functional or non-functional requirements. Creation of a new version of the APIs/Service is an example of enhancement cost. It includes the costs involved in improvement activities.

Additional Expenses:

• On Boarding Expenses: ?It refers to the cost involved in getting a new consumer onboard. It includes support required by new consumer, analysis of existing and required capacity etc.
• Subscription (Admin) Cost: ?It refers to cost involved in overheads like Metering, Invoicing and other administrative activities.
• One time versus recurring cost: consider the nature of expenses in terms of its recurrence as:

·??????One time expense (Initial, Development and enhancement cost)

·??????Recurring expense (Operations and Maintenance Cost)

API Pricing Model

Distinct API Business Model and Monetisation Strategy

API Centric Business Models

Direct consumption of products and services via APIs

·??????The business model relies on direct sales of products or services

·??????Direct sales can be to an individual consumer or to businesses

·??????APIs provide direct revenue generation for the seller

Market making enabled by APIs

·??????The business acts as a Market-Maker bringing the consumer and the producer of the services

·??????The business model is akin to that of a broker generating revenue as a commission or fees for the business service provided

Ecosystem enablement API-driven sales

·??????This model relies on the ecosystem partners who are responsible for making the sale of the products and services to the end consumer

·??????Sales by the ecosystem partners generate revenue

Enterprises may leverage more than one business model depending upon the nature of the APIs and the services they are delivering to the marketplace

?

Sample Business Models

1.?????Direct Consumption of Product and Service Via API

·??????Fosters sales of products and services by the producer directly to the consumer

·??????Private APIs for internal/partner consumption form a large segment of this model

·??????Examples of direct sales APIs include:

o??Amazon provides API-centric computing services (AWS) to individual consumers and businesses.

o??Salesforce, another trend setter, provides API centric “Platform as a Service” to individuals and businesses

o??A large European automotive company enables individuals to change their engine performance through a direct API connection

2.?????Market Maker model

?

·??????Market Making adds value to services from producers with APIs and bring a critical mass of consumers together to create a viable business

·??????Market Making has redefined a range of industries at a global level, including hospitality and taxi services, leaving well-entrenched competition behind

·??????Examples of Market Making include:

o??AirBnb provides accommodations by connecting the traveller to the renter, payment services and location services

o??Beepi.com enables used vehicle sales by connecting the seller to the buyer differentiating with a vehicle quality inspection

3.?????Partner-Driven business Model

·??????Generates revenue by using APIs as a means of generating sales through partners or third parties

·??????In this model, a company will consume APIs from multiple partners to create service that can then be resold by others further down the value chain. The partners then, in turn, are available to repackage this service to a different set of users.

·??????Example of Partner-driven business models include:

o??Wallets in turn, enable secondary procurement and fund transfers.

o??Business Correspondents asking to independent agents for the Financial Organisations ?to promote further sales in the ecosystem?