Stratus will be attending the Data 2.0 Conference in SF on April 4th. If you’re going to be there, look us up!

Here at Stratus we’ve spent significant time pondering the future of data and are always interested in meeting up with other smart folks to compare notes.

If you’re interested in the notes on Pete Forde’s and my talk at the O’Reilly Strata Conference, Paul Miller has posted some great notes on his blog here. Thanks Paul!

Also, due to its overwhelming success (it was a sold out show) O’Reilly has already announced the 2nd Strata Conference in NYC - Sept 19-21, 2001. Hope to see you there!

Pete Soderling of Stratus will be presenting along with Pete Forde (BuzzData) at the O’Reilly Strata Conference in Santa Clara, CA on Feb. 2, 2011.

Our talk is entitled Building and Pricing the Open Data Marketplace. If you’ve noticed the data marketplace arena heat up with recent announcements from companies like Factual, InfoChimps and others, and if you’re interested in issues surrounding distribution and pricing of data this session is for you.

Use this discount code to register and you can save 25% on registration. Code: str11fsd @ http://oreil.ly/htiPlJ

It’s going to be a great show. If you’re there, please stop by to say hi!

Just a quick note here that the industry blog Programmable Web has re-published a portion of our previous post on DaaS - Pricing Models for the Future of Data. Thanks, guys!

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.

I was talking recently with a major media company that has an existing API strategy. The company has successfully deployed a read-only API, which means the API pushes content out to partner and consumer applications. It’s the classic distribution oriented media strategy. Blast (syndicate) your content out and hopefully it will get picked up and ultimately reach the four corners of the globe.

Now the company is considering enabling third-party contributors to submit content to its platform using a writable API, which means that others can submit (or ‘write’) content direction to their database. The writeable API offers business benefits since it allows an existing media company easy access to expanded content via third-party contributors and enables a marketplace effect where other authors/publishers can add content and have it distributed to a wider audience. The problem is, writable APIs open a host of security issues ranging from inadvertent errors to malicious hacks. 

Here four possible scenarios:

· A partner accidentally floods the API with too many submissions, or duplicate submissions, causing service degradation and/or database cruft.

· A partner submits malformed content (invalid or malformed XML, markup, etc.) that over-consumes CPU cycles when the data is processed - effectively causing a denial of service (DoS) for other processes/users.

· A malicious hacker submits rogue script code (Javascript, etc.) intended to infect end-user’s devices once they receive the content. The code could enable the hacker to take control of the user’s computer or device.

· A malicious hacker destroys content in the content management platform through SQL or script injection. A writable API that contains traditional application security vulnerabilities can have especially devastating consequences.

The writeable API allows others to submit content directly to a media company’s content management system allowing for simplified workflow and automated submission processing. It’s a good strategy for the media world overall, but if writable APIs are not properly secured, they can pose serious risks.

Interesting news on ReadWriteWeb recently - MySpace is starting to sell certain types of user data via the InfoChimps data marketplace. As we see new DaaS (data-as-a-service) offerings come on line, the MySpace model for pricing their data offers an interesting twist - the more refined the data the higher the price. (e.g. raw user data is sold at a lower price than data that’s broken out by specific geo-coded location).

The RWW article also mentions the special report in the Economist this month on the ‘Data Deluge’ that we here at Stratus agree is well worth checking out. As businesses are awash in an ever increasing amount of data, new business opportunities exist in the sale of that data as long as the distribution can be handled in a cost-effective way.

We’re excited to see the clear link emerging between scalable API offerings driving the adoption of DaaS business opportunities. API programs don’t need to be cost-centers - they can directly drive revenue when used to back premium data focued business opportunities.

Our colleagues at Sonoa wrote a response to our CSO article introducing our recent RSA talk, and it spurred a couple of thoughts here at Stratus.

The article disagrees with our title, but it appears we agree on most of the key points. There are a few detailed areas, however, where we’d like to dig a bit deeper:

1) We are arguing that REST security doesn’t exist *in practice*. There is technology to secure RESTful APIs, but it is not standardized the way that WS-* is, and people aren’t using what is available as much as they should. This was also pointed out in the recent announcement of the Cloud Security Alliance’s “Top Threats to Cloud Computing”:

2) “A simple “developer key” that uniquely identifies the sender of the request …. is just fine for that type of API because it is used to identify the user for various tracking purposes.” (from Sonoa’s post)

The point is that the metrics data is being used and it is unreliable. Whether or not this is acceptable depends on the API. If it is a paid API, it is probably not sufficient because the key is easily sniffed and could be logged/cached on every server between the caller and the API servers. Even developers of free APIs should consider that their logging and rate limiting data may not be accurate due to potential key reuse. As with all security-related decisions, it requires a risk assessment tailored to the requirements of the API. It’s important that people are aware of the risks so they can actively chose to address or accept them rather than being caught unaware.

Last week, Stratus was in San Francisco to deliver our RSA talk on REST security. Here are some highlights from our trip:

- First off, our conference session was a great success. Around 100 engineers and managers from companies like Adobe, Cisco, Netflix, VMware, and Vanguard were in attendance, proving that the security of RESTful APIs is a topic that has the ear of businesses across many different sectors.

- Hands shot up after the session for Q&A, but the best question we received was about potential interoperability between REST and SAML. It was a great question, and stay tuned for more on this topic here on the Stratus blog.

- The session also started some good industry discussion in trade journals and from other vendors:

Scott Morrison, from Layer 7, weighed in here: http://xml.sys-con.com/node/1309030

And Greg Brail, from Sonoa, posted some thoughts here: http://blog.sonoasystems.com/detail/why_rest_security_actually_does_exist/

- Some conversations produced some interesting tidbits: Netflix wants to move beyond OAuth in terms of identity/access management across many different platforms & devices; Jeff Lawson of Twilio shared some great entrepreneurial insights and told us more about the Twilio APIs that are driving VOIP applications; and Ian White from Urban Mapping shared some of the challenges of authorizing users for paid APIs when assigning levels of access and permissions related to particular types of data can prove challenging.

- Also met with several VCs interested in the API security space. It was cool to find out during a conversation with one of the general partners from Accel, Ping Li, that Accel was an investor in Reactivity, one of the earliest XML gateway appliance companies that was subsequently sold to Cisco.

All in all it was a great conference and a great trip out West. Next up on the Stratus travel schedule, the Glue Conference in Denver May 26-27!

Here at Stratus, we’re getting excited about the upcoming RSA Conference being held in SF next week. If you want a quick preview of our talk on REST security, or if you’re still trying to decide between our session or CyberWar Best Practices, check out our latest article on CSO.