The API as a marketing vehicle.
Photo “Oil vrs water” from the flickr of Joseph Robertson
More and more I am a believer in the role of software and services to help to solve a host of different issues.
Back when I worked on Microsoft in the mid 90s, the chief concern of almost any IT person was integration. Integration with legacy systems, integration of legacy systems, database integration, and so on…
While I haven’t looked at IT manager research lately my sense is that things like XML and the spread of open, web standards have eased these concerns somewhat. Today, I’m surprised when I hear about technological integration issues. Not that they don’t exist, but they seem to be less intractable and there are more people (like our development partner Sierra Bravo) who can help take these issues on.
However, the removal of tangible obstacles simply reveals far more difficult translation and integration problems – cultural ones.
Putting two systems together is typically part of putting two departments or organisations together. The structure of the systems are symptoms of differing ways of seeing the world, different ways of operating and different beliefs. As we all know, these can’t be reconciled quite as easily.
In the marketing world, we are starting to run up against these issues and I think this will only increase. In many cases, creating strategic partnerships are in the best interests of customers and shareholders. Plus, as the edges of companies’ offerings become less defined, businesses will find themselves needing to create both permanent and temporary alliances quickly to respond to new opportunities and challenges.
What’s interesting is that the practice of publishing an API completely circumvents the requirement to address cultural issues. By simply stating, “this is how and in what fashion you can work with my system,” you don’t have to change your practices and beliefs and nor do your partners. You’re free to operate the way you both choose and have simply established a limited set of ways to interact.
While the practice of publishing an API for a software service is becoming fairly commonplace, the practice of publishing an API for a non-software/service business is not. However, most of the main benefits or deliveries of companies can be expressed as software – digitally (yet more reasons why innovation will be around creating analogue to digital interfaces and vice versa) – and then be published for potential partners to use.
For example, think about a car manufacturer like Honda that is a favourite target of Tuners. Imagine if they published CAD models of their new cars in an editable format and likewise that the tuners published their most popular mods in a compatible format. Users could shop for an create custom, highly-individualized cars online. This could only benefit all parties. While Honda’s culture is probably a million miles away from the culture of most mod-shops, it would be a way for each to work together without having to confront these issues.
In a way this is another example of the ability of software and services to remove the issue of having to think too hard about acting and simply enable new behaviour.