What a crazy day. While thinking of writing something on the  concept of Real Time Search so I was doing research and came across an interesting article written by Catrina Fake, about using API for Business.

Being a Service Provider (iNetGlobal) for business this article caught my eye. Go figure! It was so way cool… I had to share it with you. In case you didn’t know, Fake is the co-founder of Flickr, along with her husband Stewart Butterfield.  First, here’s a little background on Fake, from her Vassar profile.

When Caterina Fake (’91 Vassar) set out to create an online game, she had no idea that her team’s impromptu side project would become a benchmark for social networking and Internet photo sharing. As the cofounder of Flickr, Fake created an online community where people can interact, share ideas, and create unique content. Through Flickr, people can easily share photos, tag them for easy retrieval, and post comments on other users’ pictures. Flickr isn’t simply a place to host photos. From the beginning, Fake and her team quickly discovered the value of meeting and greeting each user in their virtual community, just as they would act as hosts to their own neighborhood. This formula was an instant success, which resulted in Flickr’s close-knit community, and helped drive the Internet to become more collaborative and user centered.

Fake’s success also grew beyond the virtual community. She and Flickr’s co-founder, Stewart Butterfield (who also happens to be her husband), appeared on the cover of Newsweek in March of 2006. That same year, Time magazine named her as one of the world’s most influential people.

An overnight success, Flickr was sold to Yahoo! in 2005, a year after its initial launch, and Fake is now the leader of Yahoo’s technology development group.

Business has always been about connections. Whether it’s communication with your customers, alliances with partners, or ties with suppliers, connections are a critical part of your business.

Traditionally business development was about the salesmen with the Rolodexes who could close a handful of big deals. Today, the rules have changed. In the Web-based economy, business development is about connecting people with the relevant information at the point and time they need to consume it. Web services allow companies to do business across firewalls, reach a broad range of partners, and create new business opportunities.

The Web services model is applicable to a range of businesses, from information plays like WhitePages.com to messaging systems like Twitter to infrastructure providers like Amazon Web Services and semantic web services like Thompson-Reuters’ Calais.

The concept works like this:

A company makes a web service that is accessible via an API (application programming interface).
Each business partner registers to obtain an access key.
Using those keys, partners can use the service programmatically to get and send data.
A well-managed API gives prospective partners, or a community of developers, a way to develop an application using your content or services. They can try it, test it, and even build something that begins to scale demand for your content. Using monitoring and metrics, you can identify the handful of partners or developers that have been the most successful in helping you meet your business goals. In the process, you end up with a self-managed business development funnel that yields the world’s most qualified leads.

Using APIs as a mechanism for content and service distribution, or as a tool to allow partners to build value added services on your platform has become an enticing concept. But the question still remains: If we build it, will they come? The purpose of this paper is to answer that question by showing you how to create a successful business development channel built on a Web services strategy.

Define Goals
When developing your API, it is important to consider the ultimate goal. Do you want to promote your underlying service, deliver new eyeballs to your site, sell more products, make your content available for distribution, or simplify partner integration? Define the business objectives, prioritize them, and look at the best way to reach the high-priority goals. Initially supporting a small group of partners allows you and your company to get comfortable with an API model in a more controlled manner. It also allows you to learn how partners want to consume the information you are making available. With this experience, it is then simple to modify your API as necessary before opening it up to a larger audience. Making your API more broadly available can lead to different types of partners, new Web services, and a massive increase in awareness and distribution of your content.

A public API strategy allows for a mass distribution model. Companies such as eBay, Salesforce.com and Facebook improved the value of their Web based applications by allowing individuals and companies alike to build new businesses based on access to their platforms. Compete, Trulia, and Whitepages have embraced another model. These companies have simply made their content available to the ever-growing global population of over 15 million developers as an opportunity to build brand awareness. These developers integrate content into their Web sites and blogs, or combine the content with one or more Web services to create a mashup. Giving access to your platform or allowing others to use your content away from your site can be seen as a daunting task, requiring particular attention to control and scalability across thousands of partners. Each has the potential to produce a large audience and a great deal of new business. Setting goals might be as simple as, “We don’t want to say no to people who want to partner with us.” A good example of this comes from a company called Thumbplay, the largest mobile content provider in the US. In the first two years in business, the company implemented forty partnerships. In the first two weeks of launching their partner API, the company implemented the next forty partners. Since that time, the company has continued to rapidly increase the number of partners driving new subscribers to their service. Because they could see an immediate impact, the company decided to launch a public facing API in hopes of identifying business opportunities they never imagined.

Launch it Now
Like any new initiative, sometimes the greatest obstacle to success is simply getting started. Going from planning and development to launch takes time. Don’t get bogged down. Demonstrating a short time-to-value is critical. Create an API for a subset of your services, identifying one or two key areas of business to focus on as a starting point. It is easier to add additional services later rather than trying to build everything before you test the waters.

Your Web service interface needs security and access, quality of service measures, scalability, and service-level agreement standards. How do you provide these non-core features and still get to market quickly? A part of the solution is up to you, however, a fair amount of the necessary but unloved work can now be outsourced to the small but growing set of services providers such as Mashery. As a provider of on-demand API infrastructure, Mashery provides the infrastructure surrounding your entire Web service. Partners can self-provision access, you can manage business rules associated with your content and services, and the necessary reporting and monitoring of your API activity.

As you launch your API, it is important to know that things will change. Be prepared to make adjustments to your goals along the way. Here’s an excellent example: a large media company launched a public API with the hopes of attracting developers to build plug-ins for bloggers to leverage its content. The company successfully marketed their API using a $5,000 bounty and registered over 1,000 developers in the first week. The company quickly learned how people really wanted to use the Web services the company had made available. Based on the needs exposed by its “early adopter” business partners, the company fine-tuned its goals and focused on making more services available.

Once launched, it is important to gather input and learn how your Web services are being used, and therefore you may take advantage of every opportunity to improve the API and the overall program. Feedback from developers and partners can provide both tactical and strategic direction to optimize the new API, particularly with new types of partnerships. With feedback and experience, your web services can be optimized. Starting with a small group of partners offers rapid improvement cycles based on operationally relevant feedback, which is why releasing something “good enough” quickly is better than taking too long to deliver the perfect API.

OK so there it is, maybe tomorrow I’ll get into Real Time Search!

Related posts:

1. 101 Twitter Tools For Business Now, mains
2. 11 Cool Linking Strategies 11 Effecti
3. Evan Williams Advice For Startups In an inte
4. Top 5 Reasons For Business Blogging Blogging F
5. iNetGlobal Internet Service Success Story iNetGlobal

Related posts brought to you by Yet Another Related Posts Plugin.