Arguably, Salesforce.com and its voluble CEO brought the software-as-a-service (SaaS) concept mainstream. Today, if software isn’t available as a service, it’s considered old school. But software – as a service or not – is just a container. What makes software valuable has always been what it does to data. Now, in the same spirit of service-oriented architectures and SaaS, a new concept is emerging, Data-as-a-Service (DaaS).

People are throwing around different definitions for DaaS, but perhaps the most common one is found on Wikipedia. Here’s a derivation of it: DaaS is the process of delivering specific, valuable data, on demand, to developers and customers that they then embed directly into their applications for contextually relevant use by their end-users.

A simple example makes it clearer. Hoover’s, a Dunn & Bradstreet company, offer business data. On it’s own, it’s a hodgepodge of names, titles, addresses and other company information. However, via an integration with Salesforce.com, Hoover’s streams data on specific leads directly to sales teams before they contact people to make a sale.

What’s exciting about the DaaS model is that it enables any enterprise with valuable data – not just traditional data providers such as Hoover’s – to create new revenue lines based on data they already own.

Even if companies don’t plan to sell their data any time soon, they should understand DaaS models because they’ll probably be buying their data this way before long. That’s a good thing. Imagine a large-company division with $100,000 to spend on its market research activities. Managers can easily spend the full amount with one data vendor, leaving nothing for additional needs. With a DaaS model, they can access very specific data, pay just for what they need and pipe it straight into internal applications, thereby meeting needs better while stretching budgets farther.

DaaS is made practical by web-based application programming interfaces (APIs). Web APIs, of course, have been around for a while, and they have been exploding on the IT architecture landscape over the past several years. For instance, media businesses deploy APIs to make free content available to developers who in turn build apps for niche audiences. The benefit is increased distribution of their content and traffic for ad-supported sites. Also, SaaS companies offer APIs to let external developers add capabilities to the SaaS software for free. The benefit is increased capability without additional developer salaries. The Salesforce.com API is an example of a platform-extending API, and the Facebook API is an example of both an ad-supported and platform-extending API.

Here’s the catch; for many companies, free or open APIs don’t make sense. Building a vibrant API developer community takes time and effort, both of which can cost more money than the incremental marketing benefit or free-developer cycles justify.

However, as a recent Economist article noted, we’re now a society awash in data. Business and finance data, location data, and proprietary data across industries have value. And savvy businesses are rushing to monetize it. Even an Internet users’ “data exhaust” (i.e. the data left behind via a users’ browsing habits and web clicks) can be mined for valuable insights on interests and trends.

Enter new lines of business that are gearing up to profit from data interchange. To do so, they’re opening APIs as revenue centers, not cost-centers. Business models are developing rapidly. A look at some of the early examples could spark creative thinking about the DaaS opportunities for any company that produces or uses data.

DaaS Pricing Models

Based on market research we’ve conducted, companies are converging around DaaS pricing models based on tiered access to the data. The tiers fall in to two basic buckets:

Volume-based model
There are two main volume-based pricing approaches: 1) quantity-based pricing and 2) pay per call. (A “call” is a single request/response interaction with the API for data.)

With quantity-based pricing, companies charge based the amount of data a customer or partner needs to access via the API. For instance, a tier might cap at 5,000 API calls per day or 100 API calls per minute. This is the easiest DaaS pricing model to implement, but it does not address overages. Another quantity-based option is the “fire-hose” approach offering unlimited volume with no restriction on number of calls made to the API.

The second option, which is more appropriate for lower-volume use, is pay per call, which involves charging a set amount, such as a few cents, for each call to the API.

Data type-based model
Another model separates the pricing tiers by data type or attribute. An example is a mapping API that offers the geo-coordinates and zip codes of the neighborhoods in an urban area. Additional attributes could include school or post office locations, which are sold for an additional charge.

Data can be sliced and diced in many ways. The most complex pricing models combine value with volume charges to create finer-grained pricing to better meet both the buyers’ and sellers’ needs.

Here are some examples to help illustrate some DaaS models:

Urban Mapping is a geography data service that allows real-estate companies and others to embed data into their own sites and applications. It offers thousands of geographic data attributes priced and delivered on demand. Examples include population density, crime levels, traffic patterns and nearby public transit stations. In addition to providing its partners with different pricing for different types of data, Urban Mapping also segments tiers based on volume.

Xignite provides financial market data on demand via an API. The company lists banks and investment advisors as clients. It’s easy to see how piping stock prices and earnings announcements into financial models is valuable. The company also has a fascinating case study on how McDonalds used its DaaS service to power a website that helped stockholders price their stock after a split between McDonalds and Chipotle. Xignite charges for its data by both volume and by types of content.

These two companies have sophisticated DaaS models that require advanced features in their core API. For example, they include interfaces to enable developers to self-register for API access and access the data they’re interested in. The API also tracks and bills for data usage in a granular way.

An example of a less sophisticated DaaS model is Hoover’s. It offers a paid API for its business database. But the way it works now, a developer registration form captures the prospect’s contact information, and several forms later into the online process, the developer still can’t access the API. Instead, interested developers must wait for a sales person to call back and kick off an old-fashioned sales cycle. It’s not a very scalable or efficient process, and it’s a known secret that many developers would rather avoid sales people.

So what do you need if you have valuable data and want to implement a scalable DaaS model?

1) You need an API. If you don’t have an API yet, you need a strategy for creating one. Think about what kind of queries end-users will be making and how your data is segmented. Get some non-technical people involved in the process to map out user-like queries and segment the data accordingly.

2) You need a billing architecture. Once you’ve defined the data available, break it into tiers based on its value to the customer. Make sure you can track the customer’s access to your data at a granular level. Typically the API itself won’t do that, so it requires robust logging and reporting functions built around your API.

3) You need security. DaaS involves money, so the security stakes are higher than for free APIs. You don’t want unqualified applications to access the data, and you don’t want malicious hackers interrupting your service or stealing your data. The first level of security is authentication, which restricts access from an unknown entity. The second level is authorization, which determines which data in the API a partner can access based on the pricing tier or plan they’ve subscribed to.

4) You need to decide whether to build, buy or partner for the DaaS platform.

Here are some key questions to determining a build, buy or partner strategy:

BUILD: Is building API plumbing a core competency? If so, does your internal team have the proven experience in deploying secure, public-facing transactional systems? Do you consider API management your core business or would it be smarter to outsource it?

BUY: Does the platform architecture support the logging and metrics granularity needed to support billing. And does the platform offer the security features needed to support financial transactions and protect your valuable data? Is it scalable enough to support a revenue-driven business? Finally, does the platform support flexible billing configurations, so you can adjust your pricing model as your service evolves?

PARTNER: Some companies partner with third-party data distribution services to get their data into the hands of customers. The key questions here are: who will sell your data better, you or your partner? Perhaps it makes sense to partner and sell directly too?

Data-as-a-service represents a new market whose time has come. The technology exists already, and DaaS-based businesses are emerging quickly. Businesses across sectors are beginning to see their data not only as fundamentally valuable, but economically viable to distribute. The scale offered by an API strategy allows businesses to unlock the value of that data for their own revenue growth and their customers’ benefit.

Pete Soderling is founder and CEO of Stratus Security Technologies (www.stratusec.com) and founder and CEO of mechanikal, a software development agency.