Transparency In The Cloud, Part I: The End-User Transformation

Apr 6, 2011 by Matt Ammerman

In case you didn’t know, the days of business-to-business (B2B) software-as-a-service are upon us.  If you’re a software developer and you haven’t begun planning a SaaS offering, stop reading this article right now, go gather your team and get started.  Seriously, you’re already late.

Ok, now that they’re gone, this article is for the rest of us: the B2B software end-users.

I have it on good authority, that in the next couple of years most of us are going to throw away our piles of compact discs and DVDs and replace them with bandwidth.  We’re going to say goodbye to license fees and free-up some square footage by dismantling our servers.  We’re then going to embrace the technologies that give us access to always-on, internet-based services which we will access from our new server-rooms-turned-corner-offices.  The benefits are manifold:  accessing software typically costs less than owning it, online services are accessible from any location and on a plethora of devices, and we don’t have to worry about things like hard drive failures when our documents aren’t actually stored on our hard drives.

The unfortunate side-effect of our herd-like flocking to internet-based services is that, by forfeiting our ownership of the servers and software that fuel our businesses, we put our destinies in the hands of software companies that, put simply, are software companies.  They’ve spent many years honing algorithms and interfaces that made us want their software in the first place but unfortunately, those years were not spent learning how to offer that software, as a service.  After all, we bought the servers, we provided the power, often times we even installed the software ourselves. Believe it or not, sometimes we’re better at running software than the vendors who sold it to us.

Fortunately, some software companies are comprised of incredibly smart people who do amazing and innovative things. They also have amazing tools available to them to supplement what they lack in experience. I have every bit of faith (*cough* SaaSGrid) that with some hard work (*sniffle* SaaSGrid), and a bit of help (*yelling* SaaSGrid), our trusted software vendors will seamlessly make the transition from shrink-wrappers to world-class service providers, without us noticing as much as a blip on our B2B, software-consuming, radars.

As end-users, we have an obligation to ensure this whole thing goes smoothly. We need to hold our service providers accountable.  One way to do that is by relentlessly asking questions. Interestingly, no one is more qualified than us to ask the appropriate questions, because we’re the ones who’ve been running software on-premises for 20-years. We know the scenarios and situations to avoid, and most of these scenarios translate into very good questions that each and every service provider should be able to answer in a way that not only gives you the warm and fuzzies but also makes technical sense.  Remember, we’re banking our businesses on these companies’ ability to learn how to provide software-as-a-service. I’d at least like to know that they have a plan.

In part two of the Transparency In The Cloud series, we’ll start a list of questions that you should ask each and every SaaS vendor you approach.  The questions are designed to help us guide the B2B SaaS transformation by making us all knowledgeable and empowered SaaS end-users.

Stay tuned!

read more

A Future of Cloud Stacks or Cloud Silos?

May 11, 2010 by Sinclair Schuller

When thinking of the cloud, there are two sides to the coin: those who build SaaS offerings and those who consume them. For those who build SaaS applications, we’ve seen a glut of tools crop up to help engineer, architect and deploy SaaS offerings. Some are “horizontally” aligned (think EC2 on the IaaS side, SaaSGrid on the application server side, etc.) while others are “vertically” aligned holistic silos (think Force.com on the PaaS side – even with the recent VMForce announcement) and some are in a mid-silo middle (think Google’s AppEngine and Microsoft’s Azure, both “up to the runtime” PaaS stacks).

Given that there is so much velocity, tumultuousness and general confusion (acronym hell coupled with taxonomical conflation – aka the “everything and everyone is a platform” syndrome), we’re bound to see some order evolve in the future where the evolution will be motivated by what people actually use and adopt rather than the current landscape which is driven by who can yell the loudest.

The big question is what will the future of cloud architecture look like: a stack of interchangeable layers that allow one to choose best of breed or a group of incompatible but highly specialized “holistic silos?”

Looking at the history of infrastructure middleware, the answer seems to be quite clear. Typically, the trend has been that layering functional best of breeds into stacks provides the best combination of “lowest common denominator” coupled with the necessary functional value to “get things done” and keep risk minimal. For example, I can choose servers made by HP, a Windows OS, Java and JBoss, and build a killer enterprise app. If I so decided, I could have swapped Windows for Linux and essentially had a compatible stack experience.  Why, then, are silos cropping up in the market?

Silos like Force.com have their appeal. They promise a world where all your needs, ranging from hosting and execution runtimes in the cloud all the way through development frameworks and distribution channels. The problem, however, is that the software market cannot be addressed as a broad stroke.

The needs of software companies vary wildly: ISVs in the healthcare space may care more about hosting certifications than someone in the CRM space, while those in business intelligence need low latency, high compute availability and the others who altogether care very little about the hosting and it’s all about what middleware they are going to use. The number of needs permutations is staggering.

To think that Platform as a Service vendors that own the full stack, from hosting through runtime and even UI components, can ever optimize for each of these scenarios is ludicrous.  Furthermore, the silo providers ask for something huge in return for a suboptimal solution:  control of the ISVs destiny in all regards. That’s a high price to pay for a promise that can’t be fulfilled.

	Cloud Stack	“Half Stack”	Cloud Silo
Operations Management	SaaSGrid		Force.com, Quickbase
SaaS Middleware		Microsoft Azure, Google AppEngine
On-Premises Runtimes	.NET, Java, etc.
Cloud Infrastructure	EC2, Rackspace Cloud,  GoGrid

I’m a firm believer that most if not all software will be delivered online. It’s the only way to achieve true ubiquity, and it requires superior delivery. Each ISV is going to have to make lots of decisions as they move to the SaaS delivery model. Those decisions are going to focus on how to best solve all the critical problems associated with becoming a service provider. The only logical conclusion is that each ISV will look for best of breed tiers in a stack form that would allow them to create an optimized outcome. I don’t see a grand future unfolding where thousands of ISVs worldwide commit to incompatible silos that require taking on relationships that amount to single points of failure and risk. As a stack becomes more vertically consolidated (i.e., more siloed), the higher the risk grows for an ISV. If ISVs take on piece-meal stacks composed of highly compatible tiers, the walk away with the best of both worlds.

What do you think? Do you think that the next generation of business applications will be split across walled silos, or will the market adopt levels of commonality by converging to a stack approach with solutions provided by a few key companies at each layer, allowing for a “composable” stack approach that we’ve grown accustomed to?

read more

How Complex Can SaaS Offerings Get?

Feb 14, 2008 by Sinclair Schuller

It’s common place to equate Software as a Service with CRM, HR, or other “business function” style implementations. Although these implementations are not simple by any means, they generally do not require the computational rigor of an offering that performs complex mathematical analysis or photorealistic 3D rendering. In fact, it’s rare to hear that a company is pursuing this sort of “non-traditional” SaaS offering.

A recent discussion across two blog posts (this one and this one) sparked an interesting discussion about the viability of the SaaS model in the computer assisted design (CAD) space. The discussion revolved around issues like data access and security, but an important takeaway is to highlight that discussions are cropping up regarding application types that were traditionally considered “desktop only”. We see people discussing CAD, and even Adobe talking about bringing Photoshop online.

It’s my opinion that almost any application can be brought online these days, and that making those applications work well is a problem whose solution is rooted in good software engineering. SaaS offerings need not be restricted to applications that serve only horizontal business functions, but can branch out into non-traditional verticals such as CAD. I would even go as far as saying that in many cases, online versions may “out feature” and “out value” desktop counterparts. Take CAD for exampe: can every architecture and design firm afford servers that can perform photorealistic rendering? Probably not, but you can bet that a SaaS provider along with a massive render farm can give that sort of value to anyone on earth.

Do you feel my take on this is too agressive? Is it too early for traditional “heavy” client offerings to move to the SaaS model?

 

read more

Enterprise SaaS != Web 2.0: A Quick Hosting Perspective

Sep 10, 2007 by Matt Ammerman

I like a good mystery just as much as the next guy, and this story’s got it all.  If you haven’t got the time or interest to read the whole forum thread, here’s the synopsis:  Jatol.com (no hyperlink provided because of said mystery), a notable web hosting company seemingly popular with development crowds has simply vanished.  Literally.  Websites down. Domain missing. Phones disconnected. Believe it or not, even the owner is missing! 

At this point, there’s not even a support number to call and Jatol.com users aren’t even able to retrieve their stored data or web site files. As I read further down the discussion chain, I started thinking about how awful it would be if I were running a web-based business in a situation like this – the mere thought of surmounting catastrophic shutdown such as this is mind boggling.

While it may seem obvious to some, this story specifically highlights a very important part of what enterprise SaaS ISVs should look for in managed services: providers that can assert serious service level agreements and back them with real ramifications.  For instance: transparent multi-tiered redundancy, consistent and thorough backups and archives, potentially even software and hardware escrow services (see ‘catastrophic shutdown’ above). The bottom line is that hobbyist devs hosting websites or even working applications with reliable hosting companies count downtime in minutes, while enterprise count downtime in thousands of dollars.

The tricky thing about SaaS is that it fundamentally requires the ISV to at least purport to be the ‘provider’ of software.  While hosting may be outsourced and ISVs become at least the ‘P’ in ‘MSP’, it is vitally important that the backing ‘MS’ be up to par.  If you’ve dealt with an MSP (without naming names) and had service level ‘experiences’, what are your thoughts on MSP preparedness for SaaS?  Are MSPs ready to host enterprise SaaS applications that generate the aggregate load of potentially millions of ISVs’ users?

[poll=6]

 

read more

Are There REALLY Multiple Strategies for ISVs?

Sep 4, 2007 by Sinclair Schuller

About a week ago I wrote an article on SaaS strategies for existing ISVs, and I see that a a parallel conversation emerged starting with a post by Anshu Sharma that claimed that in the real world, ISVs “…adopt a range of delivery model options to fit the customers need and economics of their particular business.” Phil Wainewright followed up with this post, where he vented about Sharma’s position.

I wanted to post a couple of notes on this little blog battle. First, I think the problem with Sharma’s approach is that it’s strictly customer centric. I’m the first to agree that there are (and rightfully so) a multitude of strategies (as I mentioned in my prior post), but that the decision of which to choose should be a combination of what your customer base wants/needs and what aligns with your company’s future goals and anticipated market shifts. That said, your customer might say “I want on-premise”, but you see that the market is quickly changing, with early adopters going for some new delivery model (SaaS) and its probably only a matter of time before the mainstream market (your current customers) buy into it. If you were to listen only to the customer base, you’d find yourself in trouble in the near future.

If you dig through Wainewright’s post, you’ll notice that he does agree with multiple strategies when it comes to transitioning to SaaS. This is the position I take. None of the strategies I mentioned in my above referenced post are to be permanant. Rather, their purpose is to help an existing ISV make a strategic shift toward adopting SaaS. If Sharma’s intent was that adopting a wide range of delivery models should be/can be permanant, I disagree. That’s asking for trouble when it comes to scaling the business, building new efficiencies, and having a cohesive mission.

Bob Warfield jumped into the battle with this post, where he ends on a note of a “protected game preserve” which is basically a market defined by specific attributes (size of company, etc.) where you are free to play as a SaaS provider, insulating you from the dangers of a head first mentality. This is a smart approach, and is virtually identical to my concept of pursuing a “lite” version of your product that targets a degraded demographic, giving you an opportunity to “sandbox” SaaS while you figure things out.

What do you think? Is it healthy for ISVs to pursue permanent mixed delivery models, or does this create a “dysfunctional family”? 

 

read more