I had breakfast with a good friend the other day and we covered a wide range of topics including this one – the difference between software product companies and service delivery companies. 

Service delivery companies use technology (their own or 3rd party) combined with some type of service or expertise (supply chain, brokerage, billing, payroll, ediscovery, etc.) to deliver value to their customers.  Those customers appreciate the technology being used because it enables the service but the technology "product" itself is not the star of the show.  Sort of like an iceberg in that what you see above the surface is a fraction of what is really there. 

Making the change from service delivery to product company can be dicey because all those customers that love you for your service and expertise may not be the same ones ready to embrace your product platform and roll their own as they may lack the resources, in-house expertise, or desire to do it themselves.  The path the other direction is not as perilous but still means rethinking your target customers and distribution channels as well as the impact on valuation.

Also interesting was a discussion of market dynamics and how winners are different in service delivery vs. product markets.  Product markets end up with 800lb gorillas who dominate.  The goal of any product company is to get that momentum and "win" the category.  Service delivery markets are defined by kings vs. 800lb gorillas.  These are definitely dominate players but there is still plenty of room for others as the expertise and service of the company can serve to differentiate them from even the largest player.

Software-as-a-service (SaaS) is the intersection of service delivery and software product where, in some cases, products alone work while in others it is the combination of software plus services that will define the future winners.

Enough acronyms for you?  Here's an interesting article from InfoWorld discussing a new Gartner report on the challenges and promise of software as a service delivery models for ERP. 

Some interesting points in here but mostly stuff that you could predict.  It still must be integrated.  Just because it is "on-demand" does not mean it is of instant value.  Even more interesting is a discussion of the total cost of ownership of SaaS ERP vs. on-premise and how on-premise might actually be more favorable.  Interesting.

I was in the Bay Area for a few days last week for some meetings and had a great chat during my visit with someone who really gets software-as-a-service from an investor perspective.  We hit a couple of core themes during our conversation including the notion of “consumption.” 

Enterprise software has not been easy for business users to consume in the past.  It required software, servers, consultants, and extensive configuration as well as the lead from IT to get it in the hands of the business end-users.

In the past it was about business users using software once it was set-up.  Now it is about business users individually consuming software and realizing the business value first.

This puts a new onus on any company wanting to successfully penetrate the enterprise with software and do so while avoiding bloody and bruising 18 month sales cycles.

Get all or some part of it into the hands of the business end-users first and have them begin to rely on it.  When the time comes to talk about a broad deployment that needs IT attention it has almost become predetermined.

This approach is made possible by the ability to deliver software via the internet (SaaS/on-demand).

This article came out a couple weeks ago and I have been meaning to do a post around it for some time.  It’s an InformationWeek article on SaaS integration that highlights three companies positioning to address the need – Boomi, SnapLogic, and Cast Iron.  We continue to see needs around this in the marketplace and after a bit of research and outreach, I believe the problem falls into two related but distinct categories:

1  Data extract/upload

This is predominantly for those applications that need to pull something out of an existing on-premise application and transfer it to an on-demand application once or with low frequency (think batch or asynchronous).  We can do this but our core competency is not in data extraction and this is better served by on-premise integration products or defined adapters.  In fact, many of the SaaS application companies we spoke with were using the usual integration broker middleware products for this along with their own consulting folks to get new customers connected.  Yes, this approach works but it doesn’t scale (see below).

2. Transactional processing

This is for those applications that require real-time/near-time information flow between on-premise applications and on-demand applications.  eProcurement, epayment, and supply chain applications currently fit here and this can also include multi-party information flows between two or more separate companies as well as more sophisticated business rules.  An example of this is using an on-demand CRM application to create quotes based on catalog and pricing information that exists in an on-premise enterprise application.  A single company has the need but the information flows are frequent and real-time/near-time.

Hubspan has a unique perspective on this challenge coming at it from an inter-enterprise background.  After the initial extraction and uploads occur, my view is that the needs (and approach) will evolve and become more transactional in nature for all on-demand applications. 

Until then, there is plenty of room in the pool for everyone…

Great post by Jeff Kaplan over at THINKStrategies on the difference between cloud computing and software as a service (SaaS).

Jeff should know…he’s been working in this space for some time and is really knowledgeable in addition to being a super nice guy.  If you are selling, buying, or building on-demand applications or services, put Jeff on your list for a chat.

He also did a profile piece on Hubspan recently.  Go here to get the download.

I was in the Bay Area today for a couple of meetings and had the chance to drop in on Salesforce.com's big "Tour de Force" event in Santa Clara.  I caught most of the keynote program and got to hear about the closer ties between Google and Salesforce direct from the horse's mouth as it were.  More here and here.

First off, this was a very well attended event so congrats to the Salesforce team for a great gathering.  Also appreciate the free lunch and the fire alarm going off for a few minutes was an added benefit.

That said and the reason for the title to this post is the increasing focus on how cloud/on-demand/self-service approaches to software delivery and consumption for the enterprise continue to evolve.  Two of the leading companies that have embraced the "no software" mantra – Salesforce and Google (Gears doesn't count, does it?) have further simplified the integration between their platforms.

There were a few additional profiles of companies using or building on the Force.com platform including ERP company CODA and more great stage time for Narinder Singh of Appirio.  Here's his post on it.  Lots of goodness about how fast, easy, and smart the approach is and the value of the Force.com platform (getting the point yet? [Sales]force.com is a platform company not just a CRM application company].  This left me wondering about the broader issue of integration for [Sales]force.com  Sure, Force.com represents a loaded up development platform but what if I want to connect to a legacy ERP system or connect my new Force.com enabled Coda ERP to my customers or partners?  How do I handle on-boarding, custom workflow, and change management?  The cloud is cool but the terra firma of the past (on-premise enterprise systems) cannot be ignored. 

As the clouds gather and companies like [Sales]force.com, Google, Amazon, and Microsoft vie for the top position, integration must be a key consideration including to both legacy systems and to each other.  Otherwise, we'll end up with just another closed approach to integration – keep it all on the same platform and integration isn't a problem. Isn't that what we are trying to avoid this time around?

Interesting post from VentureBeat that includes an audio interview with Gordon Ritter of Emergence Capital on the future of SaaS.  Emergence has solidified its position at the center of the SaaS universe with an exclusive focus on this model of software delivery.

Gordon speaks about the importance of data going forward and the unique perspective SaaS companies have to provide not just software services but information services.  Not just being a steward of the data but helping customers understand usage, patterns, and insights from HOW they use the software tools.  A basic (and early) example is how Salesforce currently does this with periodic emails on my usage of their product. 

The opportunity is for software companies to help their customers understand how to better use their products (ie, get more value) as well as learn in about as real-time way as possible what customers/prospects want and need.

If you’re at SaaSCon today and want to connect, drop me an email robertcpease at gmail dot com.

As baseball season is just on the horizon, I thought it worthy to frame this post around it.  Lots of interest, investment, chatter, and you could even say hype surrounding software as a service as a delivery model for enterprise consumption of IT. 

So how much of this is actually being used in the enterprise? 

A report out of Goldman Sachs (via Mitch Betts at Computerworld) lays out that we are just in the early days of SaaS adoption in the enterprise.  The results of the survey of 100 CIOs states:

"…39% of companies still not deploying any SaaS solutions, while an additional 43% are deploying less than 5% of their software seats through SaaS."

Also interesting was what was being adopted in the next 12 months:   

1. Web conferencing
2. Sales force automation
3. Learning management systems
4. Customer relationship management (CRM) outside of sales force automation
5. E-mail

Interesting question came up the other day when discussing many of the enterprise obstacles to broad-based adoption of on-demand applications.  In addition to integration being identified as the #1 barrier to SaaS adoption, there remains the question of how you centrally provision and remove users from a fragmented infrastructure that blends existing enterprise systems with one or more on-demand applications.