Interoperability between social media sites is something that’s so easy and effortless today in the consumer world, that we mostly take it for granted. For example, if you send out a tweet, you can make it automatically appear in your Facebook news feed. Sharing your favorite bits from your photo or video sharing site is usually as easy as tapping a button. Simple, easy social connectedness between all the places we keep our information online is the norm (yes, there are exceptions, but that’s my point; they are exceptions.)
Consumer quality integration, however, is much less common for enterprise users. Integration between business applications typically comes at great cost because of its bespoke nature as well as the usual development, security, testing, and manageability requirements. While enterprise applications, including social ones, increasingly have open APIs to make it easy to connect together to other systems within the organization, it still largely requires custom development of the “glue”. Most industries today now have some kind of XML interchange definition for them, but the early one-size-fits-all nature of such consortiums ensured that the the result was so large and bulky that it was usually something that only a specification writer would love.
For its part, the Web has proven that it doesn’t have to be that way. Instead, the online world has settled on extremely lightweight and straightforward integration models that are easy to understand, use, and adopt. For example, JSON andREST are common models today that encourage both simplicity and high performance. But it’s not necessarily the technical aspect of Web APIs that sets them apart from the enterprise. It’s the implicit belief that integration is a virtue to be cultivated and is often a first-class citizen along with the user experience (UX) itself. It’s increasingly less common to see new Web applications appear without a good API to match, since startups have long ago learned that if you have anything good to offer, much — if not most — of your usage will come via the API and not the UX.
Over the last few years, we’ve seen enterprise APIs become simpler and more Web-like, driving up the likelhood and ease of integration while simultaneously lowering costs. On the Web itself, the push has been for less and less complexity, with recent API trends moving towards almost radical simplicity including a growing emphasis on lightweight approaches like JSON.
New progress with customer service APIs
Now we’re finally beginning to see the convergence of the latest trends in open APIs with enterprise applications and collaboration. Last weekNetworkedHelpDesk.org, an industry association dedicated to creating standards that enable “a seamless communication stream among multiple partners and suppliers to deliver an awesome customer experience“,announced a new API to connect together customer service applications. Members include 18 organizations so far, including such notables as Atlassian, New Relic, Pivotal Labs, Service Now, SugarCRM, Twilio, and Zendesk.
The premise of NetworkedHelpDesk.org is similar to the one that’s driven most social media to be connected together closely today. Currently, large organizations use many different systems for project management, customer relationship management (CRM) and customer support solutions that are spread across multiple partners, suppliers and departments. NetworkedHelpDesk.org is hoping to make it much easier to tear down the barrier to integrating across this domains today and provide a uniform way to connect applications and organizations to each other to achieve “seamless collaboration”.
The current NetworkedHelpDesk.org API specifies a lightweight method for enabling high value integration scenarios between different kinds of customer care systems in a supply chain. For example, a customer care desk, a CRM system and bug tracking system could easily interchange uniquely identified tickets between the systems. This would, for example allow a customer’s problem to be handled by more accurate, faster, and closer collaboration between say, the customer services team, the help desk, and developers. In other words, in an increasingly Social CRM world, this API allows compliant systems to more easily establish open CRM linkages at lower cost, in a similar way to the simple setup required to connect your Twitter account to Facebook. As customer care tickets are recorded, all necessary data can be exchanged, synchronized, and shared.
The visualization above shows one of the many possible scenarios that simple, open business API standards such as the NetworkedHelpDesk.org API can enable. Instead of building expensive, custom interfaces, the two systems can quickly connect with just some configuration (since they both understand the interface) and CRM partner A can delegate tickets to CRM partner B, if say partner B is better at a particularl type of problem or otherwise more suited to dealing with the customer in question.
This is the same way that newer social Web technologies like OAuth have been enabling social networking sites and other Web applications systems to quickly and securely connect together, or that Amazon’s simple, easy-to-consume APIs have driven widespread adoption to hundreds of thousands of partners. And how RSS and now ATOM have loosely coupled the entire Web together.
Success factors for modern enterprise APIs
I’m always wary of any API that is too special purpose (because it can’t be broadly reused in many situations), I believe NetworkedHelpDesk.org API is a great step in the right direction for a number of reasons, most significantly because it’s a genuine attempt to build on what we’ve learned in terms of making it very easy to connect to and collaborate across different Web platforms. The enterprise APIs of the future, social and otherwise, will typically be successful for the following reasons:
- Simple. The NetworkedHelpDesk.org API is expressed on a single Web page. It’s easy to comply with, won’t have too many alternative interpretations, can be understood by any level of developer, and has fewer holes to exploit from a security perspective. The chance of an standard of being adopted is inversely proportion to its complexity, so shorter is better. Simple is also more scalable in today’s deeply connected, cloud-based, ecosystem-oriented world.
- Doesn’t reinvent the wheel. A good API builds on top of the shoulders of giants. It doesn’t invent its own markup language (JSON, XML, plain text work great), its own security system (HTTPS and HMAC), transfer model (REST is usually best), unless there literally is no other choice.
- Browser and smart mobile device consumable. Browser-friendliness is one reason that JSON is so popular, but now API developers must closely consider iOS and Android consumability as well.
- Aimed at a common, recurring problem. Trying to solve too many problems results in an API that doesn’t solve any of them very well. Stay focused on a particular problem and doing it very well is the secret to API success.
- Web-oriented. The applications and services of the Web have been forced to solve problems in scales that even the largest enterprises just don’t have to deal with. In addition, the Web is the primary de facto channel that the applications of the future will have to deal with. Having any impedance with the Web will ensure the API adoption will decrease as soon as a better alternative is discovered.
- Social media friendly. Social media is now the dominant form of person-to-person communication on the Web. While not every API will need to concern itself with social media, just doing simple things like using ATOM, short links, and social identities via URL can go a long way. Deeper alignment with the activity streams standard and enterprise OpenSocial may also help.
Though some consider this discussion to be about “plumbing”, nothing could be further from the truth. Collaboration is about working together, and when we can work through our IT systems to connect with each other simply and easily in the ways that make knowledge flow to where it needs to be, only then will we have achieved the real benefits of our investments in IT, applications, and networks. This is something that the Web, especially in the social media realm, has really been a shining beacon of success. Simply put, these wins should be moved into our organizations now that we’ve isolated and increasingly validated the success patterns of enterprise APIs.
At the end of the day, enterprise integration today is still far too difficult and expensive, and now we know it just doesn’t have to be. I’m hoping that initiatives like NetworkedHelpDesk.org API will help demonstrate this more conclusively and spur much needed improvements.