SaaS

Why IT can be OK with users managing their own SaaS services contracts

I just returned from Forrester Research Inc.’s Services & Sourcing Forum in Chicago. Newsflash: Chicago is a windy city! Another newsflash: The road to creating and managing IT outsourcing contracts is a long and winding one – especially when business users start procuring their own services, such as applications via Software as a Service, or SaaS.

When my colleague Christina Torode covered the Burton Group’s Catalyst conference this summer, the buzz among IT executives was that business users were purchasing SaaS services without running these agreements by IT first. As Torode reported:

“Business users tired of waiting for IT to provision a new application or service are tapping cloud providers and bypassing IT along the way, much as they have for many Software as a Service applications over the past few years. And cloud providers are not calling on the IT department, but rather going to department heads to pitch their wares.”

But if this trend makes it harder for IT outsourcing contract professionals to oversee the company’s IT assets as a whole, there is also a flip side: When business users procure their own software, it doesn’t come out of the IT budget.

During a breakout session on SaaS services and cloud computing outsourcing contracts, Forrester senior analyst Liz Herbert said that she’s heard that some IT outsourcing contract professionals would actually prefer that individual departments continue purchasing their own SaaS services for this reason. In this economy, with all budgets and spending being scrutinized so closely, why make it look like IT is doing the spending if these other departments are willing to foot the bill?

To be fair, I noticed some snickers from the IT contracting professionals in the room upon hearing Herbert’s comment, so perhaps it’s not a common point of view but I thought it worthy of mention nonetheless. Certainly, it speaks to the need for governance in IT outsourcing contracts on an enterprise-wide level – a subject I’ll be delving into in the coming week.

Has your IT organization surrendered oversight of SaaS services contracts procured by the business, or do you still intend to oversee all these IT outsourcing contracts throughout your organization?

SaaS BI vendor LucidEra’s demise harkens to ASP downfalls

When my inbox began filling up with all the theories of why BI SaaS vendor LucidEra is expected to close down by month’s end, I couldn’t help thinking that the more things change (in name, at least), the more they stay the same.

LucidEra is in part a victim of a down economy, just as application service providers (ASPs) were in the late ’90s/early 2000s when the dot-com bust happened and VC funding started to dry up.

Like ASPs USinternetworking and Corio, LucidEra was one of the first to the SaaS BI parade. It had to lay new ground in many ways: The Web technologies that today’s SaaS vendors tap into weren’t around when LucidEra got started, so the company had a bigger learning curve and had to do lot of the development itself.

LucidEra told ThinkStrategies’ Jeff Kaplan that newer kids on the block learned from LucidEra’s mistakes and could skip many of the development cycles and bumps in the road that the company had to go through.

Back when next-generation ASPs such as Salesforce.com were getting started, they certainly didn’t try to go out and buy large data centers to essentially foot the infrastructure bill for enterprise customers, or try to retrofit Oracle’s or SAP’s licensing model to fit a multi-tenant one like first-generation ASPs had.

No, they, and other ASPs — now called SaaS vendors — learned from the mistakes of first-to-market ASPs like USinternetworking (USi), now part of IBM, and Corio, also now part of IBM.

USi and Corio came out the other side, but there are others that simply disappeared. Like ASP FutureLink, a company that many, including Microsoft — which sank $10 million into it — had high hopes for.

But all the buzz around so many of these players didn’t bring in enough customers to support them all.

Similarly, today there is a lot of interest in business intelligence and in the SaaS model. But is there enough interest to support all of the SaaS BI vendors?

Economy and customer adoption aside, LucidEra had a unique set of circumstances, including hooking its wagon to Salesforce.com. It is always risky to ride the coattails of another company, as USinternetworking and Corio found out by relying so heavily on Oracle and SAP.

And LucidEra did choose a niche in sales analytics. “One problem that [LucidEra] ran into was that not a lot of Salesforce.com customers saw the value-add of what they had to offer,” Kaplan said. “And to a greater extent, a lot of folks today think having analytics is a luxury they can do without.”

Some competitors believe that LucidEra’s downfall was its older code, developed in the late 1990s by Broadbase Software, the argument being that such code was not designed for the SaaS model. “I believe that it is difficult to retrofit a SaaS approach to an existing architecture and, unless designed as a SaaS application – multi-tenant, SOA, layered architecture than can scale horizontally – cost-effectively scaling the solution is incredibly hard,” said Wayne Morris, CEO of SaaS business intelligence vendor myDials. Morris expands on what went wrong at LucidEra on his company’s blog post.

Meanwhile, Brad Peters, CEO of SaaS business intelligence vendor Birst, chalks up LucidEra’s expected shutdown to the company’s standalone analytic software approach, as opposed to most companies’ need to analyze data from multiple sources, something that LucidEra’s software wasn’t set up for, he said.

All in all, the comments I’ve seen on blogs say this is not a sign of the on-demand model’s going away — not by a long shot — but a demise that happens naturally when a lot of companies crop up in one space. There are bound to be some that just don’t cross the chasm, as Geoffrey Moore would say.

Cloud computing: You pay your money, you make your choices

MIT’s Kirsch Auditorium was standing room only last night for a forum on cloud computing, part of the university’s Innovation Series for entrepreneurs, investors and patent attorneys. But there was a liberal sprinkling of technology types as well in the audience, including some upper-level IT folks trying to get an early read on what cloud might offer them.

The forum’s avowed purpose was to give a sense of what’s real now in the cloud and so it focused on the Amazon Web Services ecosystem. Several speakers spoke of “hundreds” of providers of value-added layers to the basic Amazon services, much in the form of middleware. When you peel back the layers of the onion, in many cases what you are renting has a high open source content. If enterprises have been slow to widely deploy free or freeish open source software internally, will they be quick to pay for it in the cloud just because someone has done the initial heavy lifting of configuration?

Other vendors have more novel models. Take Allurent, for example. They’ve distilled down many of the more desired features of e-commerce websites into a set of modules that run in the Amazon cloud. They do some design customization, but seemingly a lot of the time-and-money uncertainty inherent in the handoff from graphic design to software design that plagues so many Web projects has already been boiled out of the designs.

There’s also an accompanying content management system that your marketing department can use to manage sales, promotions, etc. The pages are hosted on Amazon but appear as part of your site and integrate with your e-commerce back end. My point isn’t to do a commercial for Allurent, but to point out that the cloud model creates some new ways of doing things that may well be an improvement over current ways.

Next week, VMware will shine a spotlight on the private and private/public hybrid cloud notions. This conference was more about the platform and application services that you will likely find coalescing in the cloud in the near future. If cloud flops, it won’t be for a lack of choices.

SaaS integration easier said than done

Questions for you Software as a Service (SaaS) devotees about SaaS integration:

Did your vendor give you enough information up front about the potential difficulties of integrating the SaaS application with your existing applications? Were you able to find SaaS user groups to vet concerns before signing on the dotted line?

I am asking because I recently heard a panel of Boston-area IT and business executives talk about their companies’ experiences with SaaS implementations. One company had just gone live with customer relationship management (CRM ) software from Salesforce.com. Another talked about her firm’s implementation of a time-tracking and scheduling system from OpenAir Inc. The largest company there was weighing whether to go with Salesforce.com or the CRM on-demand offering from Siebel. The company had just gone through a labor-intensive migration to an on-premise Siebel CRM solution! (I can’t name names: Press is tolerated at these seminars but only as flies on the wall — ugh, not a very appetizing metaphor on the eve of Thanksgiving, sorry.)

All three sounded like happy campers (the flexibility! No capital investment! No server room!) until the moderator probed about integration challenges. Whoa, Nelly! Out came the sob stories, snags and second-guessing. The guy whose company had recently gone live with Salesforce, for example, basically said his team grossly underestimated the technical conundrums that can occur when there is a “significant difference” between the technology of the in-house database and the Salesforce.com “family” of apps and tools. He said that for all the attention they thought they had paid to integration, it wasn’t enough. In retrospect, they should have done a sample movement of data.

“We discovered, frankly too late in the project, that the original technology approach was just not going to work.” In fact, they had to switch integration tools midstream.

Asked if the snags were a matter of his company not asking the right questions or a vendor failure to understand the problems of clients, the guy politely acknowledged it was a “combination,” then pointedly added that the Salesforce.com implementers “are very immersed in the Salesforce community and how you do integration within that community, but what we were doing was going outside that community.”

The kicker? On the question of how this SaaS integration compared with other software integrations he’d done — just as hard, or less so? “I think it is substantially harder just because of some of the unknowns in the process.”

The OpenAir gal? There were problems mapping billable and nonbillable expenses to her firm’s accounting system. Manual checks were still required to make sure the coding was right. But the biggest adjustment was having to modify the firm’s business processes to fit the software. As for the big company trying to decide between Salesforce and Siebel, he’s keeping a close eye on how the CRM on-demand solution will integrate with Business Objects reports that currently feed so nicely into his company’s on-premise solution.

All three panelists said that what was really needed was for the SaaS vendors to go public with the potential problems customers will confront if they are integrating outside the family of apps pushed by the vendor. User groups would help. And the user groups should not be for just existing customers, but for prospective customers before they sign the contract.