Realizing API Investment: The Ultimate Team Sport

This is an article from DZone’s 2022 Enterprise Application Integration Trend Report.

For more:

Read the Report

The equivalent of a Little League Australian rules football match involves a dozen or more groups of 7- to 10-year-olds playing on the field at halftime. Bubbling over with enthusiasm and energy, they quickly put up temporary posts and get going with firm but gentle supervision by the volunteer referees.

Typically, the young players on both sides crowd the ball wherever it is on their miniature pitch. It’s as if a pack of children are magnetically drawn to the ball, chasing after it wherever it goes. No player is out on the edges or holding back waiting for the ball to be passed out for a quick run or a big kick.

In sharp contrast, as the adults and pros return to the pitch as full-sized teams, they take up the roles and positions that reflect their skills or natural advantages of height, speed, or reactions. Tall, adopting defensive roles, meanwhile, strong players tackle and pass the ball out to their fast,mble teammates on the wing for opportunities to score. When working together in harmony like this, they play to each other’s strengths while focused on the shared aim of the team’s success.

Avoiding Organizational Myopia

Organizations that understand the full potential of APIs benefit from teams working in harmony across disciplines such as sales, customer service, IT and data management, security, product development and marketing, legal, and finance. However, in reality, particularly at lower levels of API maturity, it can look more like several Little League games going on in different parts of the organization. Such activities are fueled by the creativity and eagerness of early adoption.

Teams often stay small and seem to focus on one dimension of the problem space such as:

  • API management (APIM) platform implementation or renewal/upgrade
  • API standards and governance
  • Single-use APIs as part of a process digitization

This approach invariably leads to islands of growing API capability and experience. It may lead to duplication or disconnected approaches to tooling, design/deploy standards, or technical execution strategies. Cross-pollinating ideas — looking at what needs to be shared and what is best left to be managed autonomously within existing teams — is a way to avoid this.

One team is typically best suited to be “the first among equals” by being logically responsible for enterprise API capabilities. It might be referred to as a center for enablement or something similar.

Over time, organizations better appreciate the strategic advantage and leadership needed to “mandate” API context. Consider Jeff Bezos’ often-cited case from back in 2002. In most cases, the API leaders or champions in the organizations need to bring practical cases to life of how well-designed and executed APIs make a difference.

“Isn’t It Just About the Money?”

There are many examples in the public domain of the potential size and scale of API impact. In 2017, McKinsey estimated that globally, as much as $1 trillion could potentially be made available through API-enabled business models. However, there is a practical challenge for people using this type of insight to support their business case for API-enabled change: It’s hard to connect this type of opportunity to something realizable with APIs.

The case for investing in, say, a new API gateway or APIM platform can be squarely in the realm of the IT function. However, as APIs are part of a business’ strategic plans and priorities, they need to be championed by everyone. API use cases may extend distribution channels for existing consumer offerings such as via xTech for a credit card or an insurance product.

Increasingly, in B2B relationships (and B2B2C, and so on), organizations can completely reimagine current data flows — built around point-to-point integrations — and offer APIs-as-products, providing new value propositions to partners.

Arguably, such opportunities are only limited by people’s imagination. The organizations that got going early — and/or are well underway — are able to incorporate their existing growing API knowledge and experience into proactive conversations with and new or potential partners and customers.

Marjukka Niinioja and Matthias Biehl elaborate further on these considerations in their recent article on making money with APIs, noting that there are many ways in which APIs can add value beyond “direct” monetization.

Together Is Better

Working through these potential strategies calls for a diverse group of people to sit down together and participate in a conversation. They need to not just understand the current customer but be able to have a sensible conversation with the customer’s technical teams and understand the ecosystem they’re playing in. Therefore, balancing the skills and knowledge of each member is key.


Typical contributions to API strategy

Risks if overplayed

  • Technical architecture direction and API maturity roadmap
  • Engineering know-how for detailed API design and execution
  • Understanding of developers-as-customers
  • Ownership of API technical standards and associated governance
  • Provide alignment with complementary engineering disciplines such as DevOps, Cloud, data/AI
  • Conversations in other parts of the organization — such as with prospective partners or existing customers — may be happening without incorporating the latest API strategic direction
  • Wider strategic API-enabled business opportunities may be late or missed altogether
  • Technologists focused on API development become a bottleneck for API-enabled innovation elsewhere
Typical contributions to API strategy Risks if overplayed
  • Connection to organization’s overarching business strategy
  • Business/customer/partner imperatives — eg, visibility of customer pain points and/or jobs to be done
  • Understanding of customers’ ecosystem/s
  • Access to existing customers/partners for their input and feedback into API plans and designs
  • Commercial API monetization opportunities and implications for sales, marketing, pricing, etc.
  • Underestimation of the technological impacts — such as addressing underlying data quality, meeting API security needs, or following new or emerging API standards
  • Focus on innovation opportunities that prove unsustainable when scaled across the enterprise
  • Unclear priorities with other broader API-supported transformation and technology activities
Typical contributions to API strategy Risks if overplayed
  • Alignment with strategic initiatives and timing — such as where APIs can contribute to digital transformation priorities
  • Interdependency management with other API-related work across teams or initiatives
  • Support for governance processes and/or controls such as security, finance, or legal requirements
  • Management of stakeholder management and communication processes in line with existing ITenable change programs
  • Underestimation of the technological impacts — such as addressing underlying data quality, meeting API security needs, or API management platform readiness
  • Missed opportunities to get early customer/partner input and feedback into the API design and innovation processes
  • Insufficient effort put into education and adoption of an API mindset from potentially new/wider groups of stakeholders
  • Lack of flexibility in responding to change in plans and priorities once customer/partner feedback is incorporated into API thinking

A team overly represented by technologists is likely to set a good basis for establishing common standards and aligning with other engineering approaches and disciplines.

However, it likewise risks focusing too much on the tooling, platform, and execution of the APIs. This is good for establishing common standards and aligning with other engineering approaches and disciplines but overlooks the wider needs of internal stakeholder and external partners and customers — in other words, what APIs will actually be used for.

On the other hand, a team is too heavily weighted toward people who understand current business and commercial constructs risks having a blind spot in understanding a large part of the potential customer group — the developer/engineer using the API, whether they are from within or external to the organization.

A team more biased toward realizing returns from finite investments and projects — for example, as part of a wider digital transformation — runs the risk that a longer-term view of APIs-as-products will be underplayed or missed altogether.

It’s All in the Mindset

Adopting an “API mindset” and designing and thinking of APIs as products requires education, cross-functional collaboration, and operating model (re)calibration. Newer technology companies — or at least places with little legacy technology and/or high degrees of team autonomy — often see this as fundamental, as part of their DNA.

Failing to adopt an API mindset, as is more common at mature organizations, can lead to the following symptoms and consequences:

  • APIs still largely developed as project deliverables, or “better integration,” as opposed to products with longevity
  • A tendency to focus on the technology and the solution rather than the cultural and behavioral factors in changing to an “API mindset”
  • New expectations arising for supporting API producers around embedded security, authorization, risk controls, and so on
  • New roles, functions, and alliances, such as API enablement or API product management/ product ownership

The larger and more decentralized the organization’s IT/tech decision-making, the more challenging it can be to leverage the kind of opportunities that organizations are seeking to achieve with an “API mindset.”

Addressing the Challenge

Organizations who get the API foundations right often follow an approach that allows them to learn along the way. They see the benefits of an “API-first” mindset — benefits that go through the “hockey stick” curve of returns once they find the sweet spot(s) for API-enabled change. Some approaches to getting API traction and success include:

Approach Example Actions
The early APIs didn’t just solve a “real” problem Telling stories about how an API really solved a customer/partner/ employee/system problem or created a new opportunity
Starting small and evolving Resisting the temptation to overthink the API space with a large and potentially unrealistic case for investment. Instead, progress an API agenda with a small, lightweight team of specialists enabling other IT/business/digital teams to be successful with using APIs.
Balancing across-the-board and point activities Finding the right balance between supporting all parts of the organization and a specific pointed, focused activities for, say, one customer or partner segment.
Recognizing what operating model change is required and when Understanding that more of an organization’s work leads to new or refined ways of supporting internal API stakeholders as well as API consumers outside and beyond today’s organizational boundaries.
Making education, communication, and adoption an intentional activity Planning and measuring the impact of communications and stakeholder management; Giving it time and energy as opposed to just hoping early success will speak for itself.

Overall, there’s an understanding that API success comes from blending commercial and customer orientation, digital savviness, and engineering discipline.

Key Conclusions

In summary, API success is a team sport for people who’ve had the time and opportunity to learn and grow as the game progresses. Prioritizing API activities in line with customer/partner/employee needs and priorities, while building ever-maturing capabilities to support them, is fundamental to success in growing and expanding API adoption.

This is an article from DZone’s 2022 Enterprise Application Integration Trend Report.

For more:

Read the Report


Leave a Comment