This is a direct reprint of an article for DZone [https://dzone.com/trendreports/enterprise-application-integration] as part of the Enterprise Application Integration Report, published on April 21, 2022.
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, strong players adopt defensive roles, meanwhile midfielders tackle and pass the ball out to their fast, nimble 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 increasingly 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 growing API knowledge and experience into proactive conversations with existing 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.
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 be actually used for.
On the other hand, a team 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:
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.
Photograph thanks to http://unsplash.com/.
The author, Claire Barrett, is a Director at APIsFirst, helping organisations realise the full potential of APIs. She is also a founding member of The API Collective, and leader of the global Women In APIs community. Claire is contactable at LinkedIn on www.linkedin.com/in/claire-global.