Most every technology in the Cloud stack can be deployed in a Public, Hybrid, or Private Cloud model, except "SaaS Only" solutions. Among what seems to be an exploding number of SaaS Only offerings, there are an equal number of concerns on how to manage them. Earlier this year, in a webinar with McGraw Hill Construction, I noted Microsoft as being a key innovator in providing solutions to the problem through SPLA licensing methodologies. As far back as 2003 I can remember Microsoft taking the position of Software Plus services, vs SaaS. I always felt like part of this was to clarify that you could buy their software, you could subscribe to it, or have a combination through a hosting partner. My company being one of those partners, it clearly made sense to me. But let's dig deeper and see why it benefits customers...

This concept of SPLA gave customers choices that could evolve with their business needs and whatever those needs were, enable them to stay with Microsoft. For example; a customer might start on premise (private) to try something out and then move it off premise (public) for a different service level requirement. Initially the customer would have to pay to switch, but this has loosened up greatly as of mid 2011.

Enter SaaS, specifically SaaS Only. The older scenario (pre/post SPLA) used to be making a decision between the deployment model, on premise/off premise, but basically using the same technology. If a customer wanted to move for service reasons, they could do so while suffering minimal pain by moving, vs. moving and implementing a new product. Now that SaaS (and SaaS only) is full steam ahead, customers must be extremely careful not to get caught up in SaaS Only vendor lock in.

The vendor position is they can make it available cheaper and faster. The customer position is I need to put it where I want it. Both valid arguments, but I can tell you if the product is ready for distribution, most vendors are not advanced enough in development practices to avoid the reality that they have to develop on the same cycle, regardless of how it is deployed. The two main realities I see are either the product is not stable, or the vendor is concerned about issues like backward compatibility, support, etc... Again valid concerns depending on your role.

Within the AEC space, I see a few specific recurring results of SaaS.

1) I see a lot of software products being launched as SaaS because the vendor has difficulty delivering an installable product.

2) Because of point 1, I see a lot of vendor lock in due to SaaS. I talk to companies all the time that have issue with this service lockin.

Although not impossible, I've rarely seen a SaaS vendor deliver the same level of quality in product as a company that focuses on Software only. Conversely I've rarely seen a Software Vendor turned SaaS vendor deliver the greatest service.

Clearly one solution here is that software vendors follow the Microsoft model, come up with licensing that has parity over a 3 or 5 year term regardless of the where it resides and how it is paid for. (See Sharepoint for a great example). Not only does it separate software cost from deployment method, but it solves a few other win win issues.

1) Service providers have to get certified, thus resulting in more experience based interactions with the vendor. This is a bigger issue the smaller the vendor. My company works with some vendors that don't support us at all, and thats fine since we have built our on service skill sets.

2) Customers get more options and can put the value on quality of service & software separately, vs. trying to figure out bundled, single source options where it is near impossible to delineate software and service costs.

3) Customers can avoid the often painful process of moving when they realize that they are locked in and not only will they have to move, they will have to migrate, and implement a new product. This generally ends badly for everyone but the SaaS Only provider as this type of forklift & implementation is so costly, many customers just deal with the issues.