The SaaS Swivel, Double Line, and Rig Setup

Dec 11, 2006 by Sinclair Schuller

I’ve been keeping tabs on an interesting company named Swivel for a little while now. I bumped into their blog recently, and have read a couple of articles, including one by ZDNet blogger Mitch Ratcliffe. The basic idea behind Swivel is to be a central place for intelligently parsed and analyzed data for use in interpretation. In essence, it is an “Analysis as a Service” (AaaS) platform (For the record, I hate making up names/acronym/phrases, but for lack of a better description, I had to). From my understanding, one can upload oodles of data, which the Swivel compute farm then operates on and provides analytic cross-sections of. Through these cross-sections, you’ll be able to extract valuable correlation (although I think that if Swivel is successful, it will catalyze the abuse of passing correlation on as causation. I have enough of this reading Digg). You don’t need to be an oracle to see that there is huge monetization potential around this concept. Right now, the Swivel website is very consumer, fun-data centric. Long-term, however, Swivel can be positioned as the analytic store-house for corporate data that requires analysis. Companies could add data (Ratcliffe suggested something akin to Amazon S3, which is a superb positioning in my humble opinion), let Swivel do its magic, and then interpret the neatly digested data for competitive advantage/market analysis/etc. But what’s more important is how a service like Swivel plays into the SaaS ecosystem and can benefit the end-user in a more general, more pliable case: integration. Bear with me on the forthcoming analogy.

To anyone that takes fishing seriously, the offshore swivel knot will be familiar to them. For those of you that aren’t anglers, the offshore swivel knot is generally used for big-fish trolling in deep sea or large fresh-fresh water fishing. Normally, you attach a swivel and clip to a fishing line (or in this case, a double line). The swivel and clip allows you to quickly remove a lure/rig from your line and snap on a different lure or rig without having to untie & retie. The offshore swivel knot is a special way to tie the swivel to the line such that there are multiple strands of line attached to the swivel. In the event that one strand snaps, the others can still provide support, hopefully long enough to get the fish onto the boat. Your choice of lure/rig to attach to the swivel is dependent on what type of fish you want to attract. Here is a diagram summarizing the knot and final setup (borrowed from Fishing Cairns):

(bigger)

This entire fishing setup is analogous to where I see Swivel and their value proposition fit in. Swivel has the potential to allow many different SaaS applications to tap into it’s tightly wound data without having to jump through hoops. Through Swivel, multiple (different) SaaS applications can tap into strong, reliable analyzed data without repetitive integration headaches, similar to how the clip allows an angler to attach different lures to the same, reliable knot. If a knot strand breaks, or analytic cross-section weakens, you have many more to rely on. Data and its analysis is part of the “special ingredients” involved in making any good application. Something like Swivel, horizontally coupled across different applications, will be ultra-beneficial to end users. They use the right rig (application) for the right fish (business need) without the hassle of having to retie the rig (integration of complex data).

Swivel and the concept of a data analysis platform are very exciting. I frequently go to Italy to visit family, and during one of my trips, an uncle said “Vai al mare, se ben vuoi pescare.“ The idea behind this proverb is that if you want to fish well (aka catch big fish) you need to fish in the sea (that’s where the big fish live). Well, the Internet is our sea. If they get it right, company’s like Swivel will definitely become a standard part of the tackle box.

read more

SeeControl: On Demand Inventory and Supply Chain Management

Dec 1, 2006 by Matt Ammerman

SeeControl provides inventory tracking and supply chain management tools On Demand. Recently, they appointed Al Cohen as President and CEO. SeeControl is an example of On Demand’s appeal to widespread horizontal markets. We’re excited about to see where they take hosted inventory and supply chain management in the future.

read more

What is SaaS? The Answer is Rooted in the End User

Dec 1, 2006 by Sinclair Schuller

Wow, talk about a (relatively) hot topic! Recently, a web of blog posts full of coined terms, rebuttals, and re-definitions was spun by some of the blogs I frequent. I recently read articles by Dan Farber, Phil Wainewright, David Terrar, Thomas Otter, Nick Carr, Dennis Howlett, and Vinnie Mirchandani (whew, monster list!) that discussed the topic of “What is SaaS?” After sitting it out and thinking about what I read, I figured I would finally jump in.

    One thing I noticed was the frequent mingling of concerns and perspectives when it came to the debate. In my mind, SaaS can be looked at from one of two perspectives that define the economic, use, and definition boundaries of the distribution model: End User and Provider. When we are trying to define SaaS, we need to understand that the basic definition comes from the End User Perspective, not the Provider Perspective. In terms of a purist definition, this perspective is relatively void of implementation concerns (which should be filed under the Provider Perspective). This makes it difficult for me to agree with the concept that there is a SaaS litmus test whose primary indicators stem from the Provider Perspective. Recently I blogged about “imitation SaaS” and “true SaaS”, but I should have defined the terms to indicate implementation approaches. The article does this, but alas, the two prevalent terms fail to highlight the provider perspective as a context. To summarize the notions of perspective, I mocked up the following diagram:

(bigger)

On the left, I’ve outlined the End User Perspective and summarized some of their concerns; on the right you’ll find the Provider Perspective and their concerns. The diagram has taken the liberty of stating that generally, the End User takes on the work of defining SaaS and their expectations of SaaS, and the provider takes on the brunt of implementation. The concerns from each perspective tend to align with the respective goals. Generally, a customer will look at SaaS as a new way of acquiring software functionality (notice, I didn’t say software). Many of them (particularly those on the far end of the long tail) may not care about how it’s done, as long as their needs (and therefore their definition of SaaS) can be satisfied. Wainewright and Mirchandani (the latter through a comment on Nick Carr’s post) both seem to take position that definition is predominantly a customer’s responsibility.

    The Provider has the goal of implementing SaaS. Can they participate in the definition? You bet. SaaS, however, is an economic concept whose purpose it is to provide value to the end user. As such, the purity of definition should not be adulterated by architectural/technological concepts (a nicely done taxonomy was presented in Gianpaolo Carraro’s Saas and Biology post). Architecture and technology can definitely modify/skew definition, but by no means can it supplant/provide the definition of SaaS. Please note this does not diminish the importance of the Provider Perspective. While the End User says “I Want”, the Provider is the one that says “I have, for $X per user.” If you look at the diagram, you’ll see a gradient “Realized Value” in the middle. Value is defined by the End User needs (positive movement to the left), and how well the Provider can meet or “implement” those needs (positive movement to the right). The further left the End Users go, and the further right the Provider goes, the greater the value. Who is the value for? Both. Once the End User community has reached a relatively stable definition of SaaS, the provider can continually improve upon the ability to implement and deliver. This leads to a lower cost basis, which means that either the Provider passes the buck on to the End User, thereby generating even more monetary value for them, or puts in their pocket creating a larger margin. In my opinion, the most successful providers will leverage multi-tenant, single instance because it provides maximal efficiency and value derivation; it helps the right arrow go far right. The notion of self-service support, multi-tenancy, customization, etc. all bring SaaS to the next level, but they don’t define the paradigm. That said, I think an evolutionary process will weed out many of the sub-optimal architectural/technological/business model implementations, leaving only the most efficient as the dominant approach.

Having the Provider Perspective define SaaS is like the Provider saying “You want” which is great if Provider’s are used car salesmen. So let’s not define SaaS as “multi-tenant this”, or “architecture that”. Leave the root of the definition up to End User needs. Providers, use an implementation that allows you to expand both explicit monetary and implicit functional/paradigm value.

read more