APIs Are Evolving The B2B Landscape

Phone, fax, and email. Archaic methods of communication are still the bane of corporate partnership exchanges. 700,000 fax machines were purchased between 2011 & 2012, and to this day, practitioners in healthcare and law adamantly believe fax to be the most “protected” form for sending documents.

Partners need to securely and reliably do business, and old processes can meet intransigence, even in the face of large tech momentum. Some of the traditional processes — like email — are here to stay. Nevertheless, partner integrations and information exchange is evolving, becoming more automated and programmable. Cloud computing is creating an explosion in the digital world, replacing EDI (Electronic Data Exchange), phone, fax, and email with the Holy Grail for partner integrations — RESTful API enabled B2B communication.

But B2B processes are inherently slow to evolve — such complex systems can’t possibly possess the agility of a startup to quickly adopt and test new methods. The fact is that thousands of connections and industry checkpoints are barring innovation in these complex corporate environments.

With these realities and forecasts in mind, what do we need in order to increase API awareness? How can we initiate industry momentum? The answer lies in properly communicating a superior business value. This means revisiting how APIs are discussed — with the goal to describe an inherently subject matter so that ‘APIs’ can rise above the constraints of D2D (Developer to Developer) communication, and enter the everyday B2B (Business to Business) dialogue.

In With The New, Out With (Some) Old

Just because old processes are ebbing doesn’t mean they will fade forever. Sumit Sharma of Mulesoft predicts the future will see API communication replacing some EDI modes, increasing interoperability throughout the B2B world. Though in the rear view mirror, phone, fax, email and EDI — the transfer of data from one computer system to another by standardized message formatting — are still huge and necessary players in international business.

Watch Sumit Sharma from Mulesoft present at a Nordic APIs event.

The Clothing Chain Example

To hone in on a real world example, it’s estimated that Li & Fung, a global supply chain manager, processes orders for 80% of the clothing produced in China for the US. They handle the specifications for communicating with factories and distributors all throughout the world.

Within such an enormous system, coordinating order clothing production specs (various components like quantity, size, color shade, print, etc.) with thousands of factories throughout quasi-digital areas in rural China means spotty internet availability, stalling the advance of APIs to replace old modes of communication within that industry.

Sharma contends the reality is that EDI is here to stay for a while, but a hidden API behind all transactions would be ideal. Speaking with Sharma, a Li & Fung representative expressed interest in using small cloud applications to assist this process if it were possible.

B2B 15 Years Ago: The Progression

Let’s take a quick jaunt through web service history to get some perspective on where we’re at right now. 15 years ago, service-oriented-architecture (SOA) was the hot mode of B2B interoperability. For businesses facing partners, this was the first level of abstraction of their services. Then came the SOAP protocol for accessing web services, exposed as cloud services, and instigating machine-machine interoperability.

Depicting API history as the progression of lithic-wielding ape to RESTful human, Sharma outlines how monolithic apps led to architect-led APIs for SOA, leading to APIs for web, mobile, IT, and cloud. In the future, Big data business driven APIs represent the next stop in this natural evolution. Sharma believes this trend shows movement from a machine-machine process to a more accurate representation of the smart business-to-business process.

Why B2B Strategy Really Needs An API Strategy

APIs can increase agility by de-coupling and exposing business processes. Increasing machine to machine interoperability via APIs can erase human error, improve internal efficiency, and open up an organization to new distribution channels. With the benefits from an internal or partner API strategy so apparent, why aren’t we seeing more APIs in B2B dealings? Why isn’t REST more prevalent?

Sharma believes that it comes down to a lack of understanding, contending that “Application Programming Interface language” is inherently non-intuitive for business minded people. So, how do we convince business leaders to adopt an API strategy into their business curriculum?

“There is some paradigm shift that needs to happen so that we can get this into a business conversation”

The cloud-computing wave has taken off. With remote servers supplying thousands of businesses with remote processing, cloud computing has solidified itself as an important consideration for the modern business. Sharma believes that packaging an API strategy within the context of a “cloud-computing” discussion can help onboard some that are unsure about the technology.

We also need to convince business leaders why they need to deliver a new experience to their partners, with benefits clearly outlined. Functionality needs to be represented in relatable terms for those unfamiliar with tech specifics, and we must mitigate the risks involving API adoption and platformization. As B2B is built upon relationships, API discussion needs to be transactionally designed in a way that fosters trust.

To this end, Sharma believes a solution lies in white-boarding:

Using an outside-in thought perspective: what are we trying to achieve?
Framing the API as a product: how can we describe services in a way that is in the business mode?
APX: Increasing API user experience by designing first, before implementation.

To accomplish these goals, an API spec needs to satisfy the following:

Decrease complexity but retain comprehensiveness: Sharma encourages movement from WADL/ SOAP to JSON based infrastructures.
Use lightweight systems with built in reusability
Be human readable with clear parameter objectives and documentation.
Reflect a structure that says: “this is what an API looks like”

Getting The Conversation Rolling

With the dawn of pioneer web APIs in 2004–2006, “what is an API” spiked in search rates. Now, we see a steady resurgence in queries, increasing in number each year — reflecting the API community growth and indicating an increase in general public knowledge and attention. Now is an ideal time to revisit how to refine our discussion on web APIs, and to address concerns — on security, longevity, control, and others — that deter growth. In working through these points, we can spread awareness and promote even more widespread adoption.

API Evangelism

Within the tech sector, evangelists spread ideas, promote developer programs, and are the face for a company. Sparking industry innovation requires a similar tenacity. It begins with transforming individual businesses into platforms for growth — a process that involves spreading awareness with evangelism and internal entrepreneurship.

In our eBook, Developing The API Mindset, we outlined the benefits of introducing APIs into your organization. We also composed email templates used to disseminate knowledge throughout your company. Generating interest in this way helps introduce the topic and initiate discussion within an organization. When promoting an API strategy, it’s important to refer to examples of API pioneers, and to follow helpful resources to keep updated on the API economy.

Convincing An Architect

Firing up API discussion often meets with intransigence from API architects. According to Adam DuVander of Orchestrate, who recently gave a presentation at Nordic APIs in Seattle, some lead designers are squelching an API connected world.

These constituents might have ‘architect’ in their title, they may be the CTO, or even an opinionated engineer. Whatever their title, it’s important to realize that certain team members will be resistant to change, associating API adoption with risks and certain stigmas. To help curb this, API evangelists should arm themselves with answers to these common pain points barring API adoption:

“We can’t integrate APIs because of the lack of control”

An architect wants to touch a service. Accustomed to traditional in-house servers, an architect might be weary of cloud adoption. Functionally, the prospect of relinquishing control of third party data without granular access might not sit well either. Even with these considerations, the fact is that operations are accelerated considerably with API integrations.

Take for example the Avalara tax APIs, which alleviate a common headache amongst eCommerce providers — sorting through confusing tax code. Surprisingly difficult to navigate, varying jurisdiction zones can segment tax to the block (or even cut houses in half – as in the case of this peculiar Belgian town).

Rather than maintain a log of thousands of varying tax rates, a developer can save time and resources by outsourcing this task to a provider that is an specialist in that particular field. This is the progression of leading internet startups, such as Uber, who capitalized on the prevalence of numerous APIs to construct much of their service. The mapping, location, driver optimization, payment, and rating services within the Uber app are all driven by cloud-based APIs, making it possible for Uber to focus on their core competency — finding drivers — and the user experience rather than become an expert in all fields.

Answer: The freeing of time and resources outweighs the lack of control, and will allow our business to increase its focus on our core business value.

”Can I change that software? Can I impact it? Can I touch it?”

Weary of potential downtime or latency issues, an architect desires close proximity to any data that is put into the API. Workarounds include allowing data downloads, or even offering an on premise managed option for the API. Having these options available can help onboard architects that are weary about that lack of fine grained data control. Factual is an example of a company that does this — offering place and business listings provided via API with an option to download the entire data set for a fee.

Answer: Though we won’t have local access, it likely won’t affect processing speeds. If it becomes a problem we can always centralize the data and API.

”Is an API reliable? Can we count on consistent uptime?”

Stripe API system status

Another facet inhibiting API adoption in the enterprise context is the reliability and uptime of cloud-based services. Having a well-documented API is crucial for developer interest, but what happens if the actual service fails?

DuVander believes that we can avoid this stigma by properly communicating uptime. To ensure credibility, having a transparent log that displays API uptime is critical. Examples of this include the Stripe system status and live twitter feed, which allow transparent and helpful status updates on downtime. Other models of quality developer-facing API status pages are Facebook, Twilio, and Github.

Answer: Downtime is rare, but when it does happen it is communicated transparently. Additionally, support channels exist to help increase response time.

”How can we ensure the API service is secure?”

In the context of enterprise integration, security is of utmost importance. Though partner APIs are not exposed publicly, treat them as such with the proper security protocols. Securing systems with modern approaches that properly delegate user credentials and have a consistent policy for data access can ease the prospect of third party integration.

Answer (Hopefully): The API provider is well versed in security best practices, using an impressive security stack to properly distribute sensitive information.

”What if the API service is deprecated? Dependencies will be left high and dry!”

Especially in the public API space, short lifecycles can make product longevity a recurring issue. Google, for example, deprecates APIs nearly as often as they release new versions. So, how can partners avoid an unanticipated surprise? As the B2B context necessitates transactional agreements between both parties, contracts that guarantee consistent usage are more common, delineating access stipulations and longer operational phases. This is critical for banking institutions, for example, who require dependable technology that can withstand stand decades of use. As an API provider, you need to know where you fit in the API business model chart and clearly communicate your deprecation policies.

Answer: The provider/partner has a stable business model, and is willing to guarantee an operational lifetime that fits our needs.

For more, watch Adam Duvander present at a Nordic APIs event

True B2B APIs: The New World Is Coming

Adopt APIs into the enterprise context to accelerate business dealings — expediting a typical supply chain model, for example. With the dawn of cloud computing, companies are exchanging data and services at an ever growing rate. Collaborations are exciting, but can get messy if not executed correctly. The consumerization of IT and B2B with packaged apps and applications is evolving, and the future will see more RESTful APIs driving this exchange of data in the form of microservices and fine grained processes that organically mimic true Business to Business and human processes. Remember that APIs have the transformative power to reshape entire industries. To sum things up: