DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports
Events Video Library
Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
View Events Video Library
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks

Integrating PostgreSQL Databases with ANF: Join this workshop to learn how to create a PostgreSQL server using Instaclustr’s managed service

Mobile Database Essentials: Assess data needs, storage requirements, and more when leveraging databases for cloud and edge applications.

Monitoring and Observability for LLMs: Datadog and Google Cloud discuss how to achieve optimal AI model performance.

Automated Testing: The latest on architecture, TDD, and the benefits of AI and low-code tools.

Related

  • API Design
  • A Better Web3 Experience: Account Abstraction From Flow (Part 2)
  • Freedom to Code on Low-Code Platforms
  • OneStream Fast Data Extracts APIs

Trending

  • How to Submit a Post to DZone
  • Automated Testing Lifecycle
  • Automated Testing: The Missing Piece of Your CI/CD Puzzle
  • TDD With FastAPI Is Easy
  1. DZone
  2. Data Engineering
  3. Databases
  4. Organizations Must Provide Core Competence Through APIs (Axiom #4)

Organizations Must Provide Core Competence Through APIs (Axiom #4)

Steven Willmott user avatar by
Steven Willmott
·
May. 21, 14 · Interview
Like (0)
Save
Tweet
Share
4.96K Views

Join the DZone community and get the full member experience.

Join For Free

This is a joint post by Guest Author Craig Burton who writes at http://www.craigburton.com/ (craigburton) and 3scale’s Steven Willmott (njyx on twitter). The original axiom approach was dreamt up by Craig and we’ve iterated together since.

The Five Axioms of the API Economy

This blog post is the fourth in a series of five blog posts outlining the axioms of the API economy. The post follows on from the first three Axiom posted (also see an intro to the series in the first Axiom). The five axioms we’re covering are as follows, in order:

  1. Everything and everyone will be API enabled.
  2. APIs are core to every cloud, social and mobile computing strategy.
  3. APIs are an economic imperative.
  4. Organizations must provide their core competence through APIs.
  5. Organizations must consume core competences of others through APIs.

Axiom #4 addresses the issue of what should an organization choose to API-enable first and why.

Axiom #4: Organizations Must Provide Core Competence through APIs

The fourth axiom contains two core elements. When an Organization chooses to provide APIs:

  • Those APIs should provide substantial value to their target audience.
  • Those APIs should cover the Organization’s core competency.

In other words, an organization should provide APIs that some other individuals or organizations (customers, partners or the world at large) can consume and find useful. These APIs should generally be related to the organizations core business – and not a small side detail.

While these are separate, it’s easiest to understand them together. As already stated in the previous axiom, APIs have the power to generate significant economic value but:

  • This value is only unlocked if a particular API set has a user-base. These users may be customers, employees, third party partners or the world at large – but without a user base an API is a wasted investment.
  • An API is only as valuable as the data or functionality to which it provides access. So if an organization delivers a particular core competence (e.g. shipping, book retail, flight reservations, car hire), it stands to reason that the most valuable APIs this organization could provide link to and drive volume to exactly these core competencies.

Axiom 4 Graphic

Figure 1 illustrates the relationship between providing value to the target audience and using the provider’s core competence when designing and delivering an API suite. Obviously the provider should go for the “Sweet Spot” and develop APIs that focus on the provider’s core competence and deliver high value to the target audience. Anything less will meet with undesirable results.

In a theoretical example, a car hire firm may consider two APIs: 1) a data API providing historical trend analysis on US driving patterns, 2) transaction capability to book hire cars from the company’s fleet.
Both of these APIs are interesting and potentially valuable to someone (and both are worth considering). However, if the organization needs to choose between the two projects the second is clearly more valuable both to itself and its customers, partners. This is because:

  • Transactions on the API drive the hire company’s core business.
  • Transactions on the API help partners/customer carry out the key business with the organization in a new way.
  • The company can safely say it is likely to continue support for the API if it succeeds since it will be contributing to core business metrics.

For the second API however, while this could certainly be valuable, it represents a deviation from core business. The car hire company would likely not be able to back the API with as much resource. Further, the API would need a new, separate business model. Though this could certainly be welcome if revenues were significant, they would likely need to be very significant compared to the company’s core business. Worse, if the API gets significant traction, costs could rise – potentially forcing a shut down. In other words, this second API is a much more fragile proposition both for the provider and potential users of the API.

In order to reinforce this point consider some examples of companies who operate APIs that directly drive their core business:

  • The Walgreens API: subscription filling and photo printing
  • Nike+: social network enabled sports clothing
  • Twitter: read and write tweets
  • Getty Images API: stock photo search in real time

In each of these cases, APIs form a channel directly onto the company’s core business and if successful will drive more business (which would likely grow over time). This channel delivers a very clear advantage over their competitors since potential partners and customers now have increasing reasons to partner with Walgreen’s, Nike, Twitter and Getty Images specifically.

It could even be argued that over time, an API could become the single most important business channel for many companies, since mobile, partners, and product integrations could all tie into a single channel.

Interestingly, it has taken a while to learn this lesson. Many of the early APIs that were created by large organizations were offshoots or experiments that were deliberately not related to the organization’s core business. In other words, organizations wanted to explore the impact of APIs but not affect their core businesses – this approach often leads to failure of the API program since:

Summary

Becoming an API provider is driven by one key realization: ensuring an organization’s core competence is available in the simplest form possible for others to integrate into their own systems such that they can become valuable suppliers, customers and partners.

Also providers should enable API access to core competence and preserve value to the target audience. Focus on the “Sweet Spot.”

Note: This is not intended to be an argument that every organization should have a fully public open developer program. In many cases that goal wouldn’t meet business objectives nor would it provide value. Instead the axiom states that becoming a provider to some kind of audience – typically a subset or superset of an organization’s existing customer base, or a new one they wish to address – is the important focus. A fully public open API is simply the mechanism to reach a particular type of customer base.

Up next is Axiom #5: Organizations must consume core competencies of others through APIs.

Axiom (computer algebra system) API

Published at DZone with permission of Steven Willmott, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

Related

  • API Design
  • A Better Web3 Experience: Account Abstraction From Flow (Part 2)
  • Freedom to Code on Low-Code Platforms
  • OneStream Fast Data Extracts APIs

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 3343 Perimeter Hill Drive
  • Suite 100
  • Nashville, TN 37211
  • support@dzone.com

Let's be friends: