As we build services/APIs for use within the enterprise or cloud computing, there seem to be two clear trends for those who are consuming the services/APIs: they want to leverage APIs that drive social networking, such as Twitter and Facebook, and they want to leverage complex, business-oriented, and high-value APIs that they don't want to build themselves.

APIs around social networking are easy to define and leverage. They have simplistic data structures and well-defined methods. While they are simplistic to use and understand, they also have huge value for both the API/service user and the social network resources that expose the interface. These APIs enable many third-party vendors to leverage a social networking resource, but the hidden value will come from the enterprises that can leverage these networks as a new form of business communication.

Indeed, I'm finding a huge upside for my business as I track the movements and production of my fellow thought leaders, employees, and clients. This makes me and others on the network more productive. Thus, taking that resource to the next logical step, it's easy to see the value of integration with core business processes and productivity applications, perhaps driving many of these social networking applications from a mostly visual to a non-visual resource, or, from a Web site to an API/service.

On the other end of the spectrum are the complex and business-oriented APIs/services. These are highly specialized APIs/services that typically focus on specific business problems within specific verticals. For example, the ability to determine the risk that a shipment will be delivered by considering the on-time statistics for a particular carrier, as well as the weather, road conditions, traffic, and the chance that the transportation company will go on strike. Obviously, you have to consider hundreds, sometimes thousands of variables, perhaps integrating with hundreds of information systems to determine the results for requesting applications.

Thus, when considering economies of scale and the effort to create these complex business-oriented APIs for a single application instance for a single enterprise, they are best delivered as on-demand APIs/services, and thus will have the highest value. This will be the sweet spot for those looking to create and host APIs/services on-demand.

In addition, these services will be highly vertical-ized and business specific. This is why, for example, a phone number validation API/service may have a use within some businesses horizontally that don't host the data locally - the larger value is business-specific and complex services. For instance, the ability for a homeowner's insurance company to determine the tornado, flood, and hurricane risk statistics for a particular area using the phone number delivered to a caller ID system as the point of reference. There is a huge difference in the value that each API/service pattern delivers to the API/service consumer. You could make a nice little startup company just around that API/service offering since you could charge a subscription charge commensurate with the value.

The vision is that the hundreds upon hundreds of APIs/services that are being built now, or will be built shortly, will drive in social-oriented or complex business-oriented directions. Clearly, we'll see a day when many of the application services that are developed and hosted on-premise will be moved outside of the firewall. Not for the sake of moving toward cloud computing, or the hype that is cloud computing, but the fact that those services are much better than the services we can build in-house and they are much more cost effective.