I’ve long been a proponent of organizations that have an API-driven strategy. API (Application Programming Interface) is a term used to describe the technical integration points between applications, between devices and between services. It is, for want of a better analogy, the small piece of code that acts as the universal socket into which other tools, products or devices can plug. In a time where legendary venture capitalist and entrepreneur Marc Andreessen famously quipped that software is eating the world, APIs are the technology pieces that give software teeth.
So, given my bullishness about the API space, I was interested to hear from Atlassian about a new concept, Service Provider Interfaces (SPIs), and how they can do more, be more and achieve more.
Australian-founded Atlassian develops of a range of tools that software developers use to make their processes more efficient and agile. Atlassian markets tools such as JIRA, Confluence and HipChat. Their new approach, entitled Atlassian Connect, is a technical framework that allows third parties and, for that matter, Atlassian itself to extend and integrate into Atlassian’s products.
An SPI goes beyond simple integration and allows developers to create local functionality, connect external services and distribute add-ons to Atlassian cloud customers. The Atlassian Connect framework offers several functional areas:
- Installation management: includes requesting required permissions
- Access to the user interface: to allow add-ons to be integrated with the UX
- Connectivity from Atlassian products to external services via REST APIs (Webhooks)
- Security, authentication and authorization: to determine appropriate use of product APIs
- Add-on discovery for all cloud customers via Atlassian's Marketplace
SPI originated when Atlassian was a young company and had only a single product, JIRA. As a young company wanting to scale, the company released its source code for others to hack on and build their own features. Over time, some of these developments were included back up the chain and made part of the core product.
Initially, this was achieved through the use of Java applets. Developers coded against a Java API that would modify the core application code without forking the source code. Over time, this approach was adopted into Atlassian’s other products, and, almost randomly, a partner ecosystem grew around it. From this ecosystem, the company then built the Atlasssian marketplace, which allowed third-party software vendors to build and market products. The marketplace offered one-click installation and one-click billing.
For practical reasons, this was initially just a server offering (i.e., not available with the cloud products). Translating the approach to the cloud was hard. Atlassian was running a very large multi-tenanted architecture and couldn’t inject code that would let third parties change the core functionality.
Enter the SPI
That is where the SPI comes in. Using Atlassian Connect, third-party developers can inject new functionality directly into the core application’s user interface through a security sandbox. Essentially this is via an iFrame, with code being injected into the application on the client side. The third-party developer stands up the infrastructure to run the content within the iFrame.
This approach feel a lot like iGoogle, an early attempt by Google to offer users a customized “portal.” iGoogle was essentially a single page that offered the ability to add lots of individual iFrames into which users could feed content of their choice—email feeds, social media information, stock market tickers, etc.
The third-party developers seem to be benefitting from this approach. Tempo, which offers a planning solution, reports that using Atlassian’s SPIs has enabled them to provide JIRA Cloud customers with rich user interfaces inside JIRA that leverage Tempo and JIRA data. JIRA’s SPIs have enabled Tempo to closely integrate their data into the JIRA data model, including custom fields and search functions.
While I’m not convinced that the SPI acronym will see breakout success, the approach of letting deeper customization to be driven than regular APIs allow is useful in a large variety of settings. It will be interesting to see Atlassian’s progress with its framework and, more broadly, how others follow the company’s lead.
This article is published as part of the IDG Contributor Network. Want to Join?