Channelsales Worldwide

Roman Stanek in his October 1 blog, Please Don’t Let the Cloud Ruin SaaS, http://bit.ly/wRKCD thoughtfully took issue with the emergence of so-called “SaaS” applications (notable Amazon’s AMI) that are really a throwback to the on-premise/enterprise software  heyday of develop software a little bit and let customers take on the operational risks.  Roman clearly states this is this type of Cloud computing can have a backlash effect on true SaaS-based services, and I agree.

Roman’s assessment’ brings up the subject of what to do if a customer doesn’t know what they don’t know.   And specifically, what’s the role of a traditional, on-premise SI integration partner as they try and embrace SaaS as part of their portfolio of services?

Here’s a scenario that I’ve encountered.    When a client has a need to build a SaaS-based business intelligence application, as part of their SaaS offerings, what should the SI do to help?

• Does the SI advise its customer (a SaaS vendor) to solve the subscriber’s problem for one specific project (as in the on-premise world).  Typically, even in SaaS environments, subscribers /endusers have legacy systems (and maybe to other SaaS apps) that want to integrate with. The SI knows that they can probably deliver the project but does that serve the SaaS vendor the best?  This is a single discrete project so how can the SaaS vendor scale the project and offer the solution to all of its subscribers?

• Or, does the SI tell the SaaS vendor to start small, address a discrete piece of the subscribers’ (note the plurality here) problem in the SaaS environment and build on it incrementally?  Overtime, this incremental approach expands and all SaaS customers can enjoy of this solution available to all in the SaaS application.

These are two very different approaches and can form the basis for how a SI can effectively embrace SaaS.  As you probably know, there is quite a bit of consternation out there among SIs that SaaS takes their business away.  I propose that the SI’s business doesn’t go away in a SaaS model, SaaS just adds a new flavor to what they are used to.

So for example, instead of plain chocolate ice cream (that I crave) I recently discovered Chocolate with Ancho Chili (that I had recently at San Francisco’s Humphry Slocombe ice cream shop).  The first bite was a bit unusual, I knew it was chocolate but there was something else I couldn’t quite identify and then the Ancho chili exploded (arriba!).  After a little bit, things mellowed out and the chocolate and chili seem to blend into a great flavor and so I said to myself…”hmmmm that was pretty good, I think I’ll have some more!”

The same is true in a SaaS world for SIs.

The initial dialogue the SI approaches a SaaS project is a business unusual. There is the sense of familiarity (the chocolate):  the IT setting and the customer.   So far so good.

But then there is something unusual (the chili).  Sure enough, there are other folks in the room in a SaaS environment, folks that want to talk more about the value of the data; the workflow, the domain expertise in lieu of just how the systems connect. The experience rattles the bones for the SI (that’s the chili working) but soon, the SI discovers that he/she is still a trusted advisor;  it’s just that now the conversation goes deeper than just the nuts and bolts.  The SI concludes that the experience was ok-to-pretty-good so they decide to go back for seconds. And,this time with a bit more confidence and a little bit more of that chili.

A good SI in a SaaS environment will know how to coach the customer (trusted advisor here) and can interpret what AMI and other tools can be used (and which ones should not).  This is a good example of the how the SI can bridge the gap to SaaS, steady the course for SaaS (away from enterprise software) and enjoy the chili.