Mashup and webservices supply chain management and API risk management will be a full time job tomorrow.
Let me explain how , finishing by a concrete example on SIRI.
Today, as developer, you may use several APIs in your application, in an advanced mashup or combined application.
And then you’ll have to manage many providers, data sources, performances, quota, rate limit, terms and conditions….this is not so easy.
Also, many APIs may mean multiple API relations and API risks to manage for your application.
This is what I call Webservices supply chain and risk mangagment.
Exactly in the same way as a automobile industrial has to manage different sources of supply for car construction (tires, wheels, lights, mechanical piece etc…).
In this case, this factory has to manage competition, nomenclature, purchase conditions, performance, delivery, financial risk that the company fail on each component ! It is a huge an important work.
In a mashup or a combined application , this is the same, you’ll have to manage each, each brick provider as each API provider this way. Even more because in the cloud and public APIs it is a lean supply chain !
For the mashup supply chain, each developer or start-up needs to behave as a cloud purchase and supply manager.
Once the idea of the application or the mashup is ready, this manager will go on the cloud marketplace to find the best suppliers for its project.
These differents missions, will be :
1) Sourcing of all the API providers to find the best partners which provide an reliable API to build this mashup
2) Exploration of the API and the specificity and the quality of datas inside. In the same time, a risk analysis needs one each API provider you see to be sure it is reliable.
3) Check for performance in a free trial if possible and look for policy and terms and conditions which are in phase with your project.
4) Contact the company, or direct apply for an API key (even purchasing)to access to the API and negociate premium services depending on your need.
5) APIs responses aggregation, data treatment to make them interoperable
6) Make previsions on your probable traction and usage for scaling with yours different API suppliers
7) Optimise your delivery conditions, negociate a SLA of your different provider depending on your user performance needs, and find solution to manage performance , caching for example.
8) Don’t forget to stay aware of news API versions from your providers and keep contact with API providers to know their roadmap and avoid obsolescence of your application, and risk survey for be sure that your today supplier can supply you in the future.
This a way to manage efficiently different APIs from differents API providers in an application or a mashup.
Now some clues to understand the SIRI case !
Please imagine a API supply chain management for SIRI which gather many dozens of APIs ! It is a full work you don’t have to minimize if you want a full time good user experience and maintain your mashup for long term.
I recently had a discussion in June with the director of SIRI at Apple and SRI (Stanford Research Institute) International members, which are at the base of the AI of SIRI.
They explain me that SIRI technology, which was first SRI International one, which gathered around 40 APIs in 2010 which would gather today in 2012 around 55 APIs.
In fact, webservices are for SIRI a cloud backend with ontologies, where the application only manage tasks and the user gives voice orders as represented here.
Brian Roammele explains the concept of cloud backend APIs on Quora in his question self answered : Why is SIRI so important?
“Siri will be building on an ecosystem of Backend Cloud APIs. In its simplest form the API would declare the meaning of the data going in and out via ontologies that have been pre specified reachable by Siri on the Internet. Siri will than build a response on the Fly from the API data. The concept of ontologies-as-specification is the hallmark of Tom Gruber (http://tomgruber.org/) CTO and founder of Siri Inc and now at Apple working on Siri. Tom’s approach to the challenges of reaching out to the data on the Internet and getting back something useful is quite revolutionary in that it does not require a “Semantic Web” ecosystem. Through APIs and the land rush that I postulate will develop around this ecosystem getting at relevant data will become rapidly easier.”
To go further with a concrete example, Apple deposit a patent in January 2010 presenting a part of its SIRI first imagined webservice architecture.
In the patent, 229 pages, (so long !) they explain a lot of things and they present the vision of the january 2010 ontology and webservice architecture. You can see an concrete example about restauration ontology here and imagine the articulation of APIs behind it.
It begins to be complicated, right? And this only for technically finding where to eat…we are still not talking about performance of APIs, API ToS etc…
You can find the complete patent here : http://c2499022.cdn.cloudfiles.rackspacecloud.com/wp-content/uploads/2011/10/iPhone-Siri.pdf
when talking about all these issues, they explain me too that the webservice supply chain was so difficult to maintain for Apple from such providers and new ones everyday, that Apple has gathered everything into 5 big consistant services working together since this date, for a simpler and scalable cloud API backend.
They did not go further for me to understand exactly how it works today, I completely understand that is secret Apple know-how, that I will not know what is behind the “Walled Garden” but the fact is that they had to structure the API supply chain management because of so many webservices providers.
In a programmable web with more and more useful APIs everyday, where a lot of start-ups make their innovative product based on 3 or 4 APIs in average (often more), this API supply chain management begins to be real. You already know it with combined application maintenance ! or the changing everyday Twitter ecosystem, that even investors don’t want to trust anymore.
And knowing this, the API rating agency I am building goes in this way, to better analyse the API provider in a ecosystem developers can trust for business.