Conversations in the SaaS enablement space tend to focus on companies offering cloud application platforms (such as our very own SaaSGrid), enablement technologies such as billing services offered by folks like Aria Systems, or players like Amazon that are pushing “closer to the metal” cloud utilities like file storage via S3 or virtualization constructs via EC2. Notice something? No mention of any hosting companies! Surely to some degree the infrastructure required to run SaaS offerings is “enablement”, so why so little discussion? Generally, it’s because there has been little innovation by hosting companies to date. Many hosting companies have yet to explicitly acknowledge SaaS as something that requires more than ping, power and pipe (3P). Others that have are just starting to formulate plans around SaaS. Folks like Rackspace, NaviSite, Peer1, 7Global, Attenda, and ServePath that have self-identified as “SaaS hosts” in recent history focus on professional services around SaaS as well as highlighting why their 3P is better than others and how it will help reliability for SaaS offerings. Even companies with deeper SaaS focus like OpSource haven’t gone the extra mile to truly have huge industry impact (although they have done more than most). Little has been done to address core enablement needs required by SaaS vendors, and SaaS enablement as an initiative has basically been dealt with as a new tab on hosting companies’ corporate websites that do little more than decorate old services with SaaS marketing. I think that in the near future, however, this will all change.

Hosting companies frequently get written off as dinosaurs lacking innovation and understanding, and instead are simply here to provide “raw resources” via their 3P offerings. I couldn’t disagree more. First, from the business standpoint, hosting companies have invested millions of dollars in leveraging infrastructure and highly tuned infrastructure staff. This, if exploited, can lead to awesome economies. Furthermore, they have a history of understanding what it means to be a provider of outsourced needs and acting as an extension of their customers business, as well as dealing with “recurring revenue” models. To me, all of this identifies a clear alignment of what SaaS enablement (particularly in a PaaS world) is to those that consume it.

The big question is whether hosting companies will evolve into something beyond 3P and tackle core issues in SaaS enablement. I believe they will. We’re starting to see evidence of this in some of the initiatives that hosts are pushing. Take Rackspace, for example, who recently announced CloudFS, an infinitely scalable cloud storage solution. That’s a degree of innovation that we should all appreciate. Although it’d be interesting to see if it succeeds, what excites me most is that some hosts like Rackspace are starting to “rock the boat” and seem to yearn for an evolution (or even a revolution) toward complex value propositions that matter to SaaS vendors. I’m confident that over the next 1-2 years, we’ll see some pretty cool initiatives come directly from hosts; I can’t imagine that they plan on handing over the biz to whomever wants it and that they’re content with the idea of going gently into the night.

I just read a post over at PaaSTalk that painted a scary picture in Germany. A recent survey showed that almost half of the ISVs have no plans for SaaS offerings. Granted, some subset of those probably are in a business where SaaS doesn’t fit at this point, but I imagine the remaining ISVs are resisting change.

The problem with resisting is how staying in the on-premise world interacts with what the SaaS paradigm does to market sizes. SaaS is an amortization of sorts when compared to on-premise licenses (from the expense perspective), and as a result absolute market size shrinks or growth rate is dampened because of the marked differences in license costs (think of it as market level cannibilization). As SaaS continues to spread across the space and end users continue to accept the model, resistant ISVs have to battle shrinking market size where their on-premise license charges are significantly disproportionate. I’m not sure how those ISVs intend to deal with this and compete. My guess is that resistant ISVs will have their “lunch eaten” by a new player in the space who clobbers them with a SaaS offering.

One thing I’m curious about is the “why” aspect of those resistant ISVs for which SaaS does make business sense. Is it because of the difficulty of transitioning (cannibilization, rehashing their company to be service focused, etc.)? Is it because they think SaaS is a “fad”? Are the hurdles technical in nature? If you had to guess, why do you think ISVs generally resist the transition?

As the founder of a PaaS company, these curiosities are multi-level: why would some people stay away from SaaS and is there something that a PaaS offering can do to alleviate their concerns?

We’re in an interesting transition within the software space. Specifically, we’re all in agreement that SaaS is changing the industry in a very positive way. More importantly, however, is the recent evolution of platform as a service (PaaS), which is where Apprenda lives. Recently, we’ve seen more and more noise around PaaS (both consumer and enterprise PaaS offerings) with players such as Google via their AppEngine, Salesforce via Force.com and Amazon via EC2 introducing PaaS flavors at different levels in the PaaS taxonomy. As I’ve mentioned on other occassions, I enjoy looking at the histories of other industries and looking for lessons. One analogous situation that is chock full of lessons is the business of electricity, it’s generation and it’s distribution.

Now that more companies are throwing their hats into the PaaS arena, I’m keeping an eye on what could become a disturbing scenario. Greg Matter from Sun Microsystems wrote a blog post about a year and a half ago where he stated that “…there will be, more or less, five hyperscale, pan-global broadband computing services giants.” For the most part, this is an ok scenario at a specific layer - the delivery platform layer. Disturbingly, what we’re seeing is that some of the major players like Google and Amazon are approaching the market in a monolithic stack fashion. That is, even though their PaaS offerings are in their infancy, they seem to be adamant at controlling all aspects of the PaaS stack. AppEngine creates a set of libraries, which sits on a service delivery layer sitting atop of Google’s compute resources. Force.com creates a library and language layer, which sits atop a delivery platform, which sits atop compute resources. What I’m seeing is a disturbing trend that as an industry we should avoid. Let’s take a page from the history (and future) of the electric industry.

Transmission of electricity and power in the United States has faced two major outages; one in the 1970’s in New York City and another in 2003 that affected a majority of the Northeast. In the U.S., electricity generation and distribution are separated from transmission, thus creating functional decentralization. However, generation and distribution is highly centralized. The problem with this is that it creates large single points of failure with significant, non localized downside in the event of malfunction, is conducive to congestion, and unmanageable complexity. Now, some of these problems predominantly affect efficiencies (such as being too complex) while others affect customers (single point of failure) in near catastrophic ways. Both the blackout of the 70’s and of 2003 were costly and devastating, bringing parts of the U.S. to a veritable halt.

In 2003, I was working in Manhattan during the blackout and ended up having to walk across the Brooklyn Bridge in what almost seemed to be a pre-apocalyptic scene from a movie. This was a direct result of a poorly designed system that outgrew itself and couldn’t scale well because the centralized nature of the grid. As a result of these issues, many have suggested introducing decentralization to America’s power systems: individuals such as Al Gore have made it a key point to create a decentralized “electranet” while action groups such as the Union of Concerned Scientists have pointed to decentralization as necessary and critical to insure reliable power. We created a system that did not anticipate our massive energy needs and that unecessarily coupled at strategic layers. Now we have to do significant work to try and correct errors and prevent the cost of failure that is growing superlinearly with our growth in consumption. A majority of proposed corrections have to do with breaking a part a monolithic electric grid stack into manageable layers. Notably, this partitioning may even help create a scenario that is much more free trade friendly and more efficient: the notion that somehow this monolithic approach created some sort of benefit through tight coupling and specialization is absurd.

PaaS and SaaS (which in the future will all most likely be hosted via one platform or another) create a producer -> distributor -> consumer scenario familiar to those in electric power distribution. From my perspective, the idea that PaaS providers want to establish monolithic stacks is akin to the centralization of power generation and distribution, which comes with all the associated downside and ris. From the top down, most complete PaaS offerings will come with an API/service integration layer, a service delivery platform (SDP) layer, and a compute layer. But are these layers unnecessarily coupled?

When looked at it from the strictest sense, APIs and the underlying platform establish a well known functional contract between the application and the SDP. If a software company looking at a PaaS offering agrees to that functional contract and can extract all functionality they need from the PaaS, they commit to the PaaS at that level. Once built, applications are deployed, managed and operated through the PaaS. Service contracts exist between the SDP layer and the compute resources that the SDP lives on. This is an ongoing relationship that carries  good level of risk not measurable by commitment to the PaaS at the functional contract level. Once up and running, the opaque nature of the compute resources from the applications perspective creates a scenario where the application and its creator have little control and recourse.

A PaaS provider may start off giving you exceptional service, but over the course of a few years, performance degrades drastically. This degradation tends to occur at the compute resource layer or at the linkage between the SDP and compute resources layer. You’ve committed to the API and SDP, making it difficult to decouple. Worse yet, being on a monolithic PaaS stack, you can’t alleviate the degradation in service contract since the provider is one and the same in an exclusive relationship where by virtue of agreeing to the functional contract, you’ve agreed to the service contract both current and future. This is the same ridiculous architecture we’ve inherited in power generation and distribution. If Greg Matter is correct and things shakeout to 5 (more or less) PaaS providers, I sure hope it’s not 5 monolithic stacks. I’d hate to see the results of the first blackout. My goal is to push toward a much more resilient mechanism for PaaS, avoiding the pitfalls that come with gross centralization that is present in purely monolithic stacks. Yes, some might say “But company X would NEVER fail us” - I’m sure people also said “Our electric grid will never go down” and “Enron is too big to go out of business.” History is the world’s teacher, and if we’re wise, we’ll be attentive students.

Do you feel that it will be ok to function atop a few monolithic stacks, or should the PaaS focus be on decentralized PaaS mechanisms? What are your predictions for the future of SaaS and PaaS?

Ok, I admit that I have a fetish for buzz acronyms, but I promise the use of service oriented architectures (SOA) and SaaS in this posts title is appropriate and introduces an important topic! Specifically, I’d like to tackle SaaS implementation approaches and how these different approaches relate to a SaaS business.

When deciding on how to technologically tackle a SaaS implementation, a software company should understand their marketplace and business strategy needs. B2B SaaS offerings that focus on businesses small and large generally bump into questions like:

1. Does your SaaS offering have an API?
2. Is cross-application interoperability important?
3. Do you need interoperability across broad technologies or are you targeting a single technology for interoperability?

In today’s on-demand world, companies like Salesforce have established an expectations baseline. B2B applications are expected to have APIs, as well as the ability to bridge technology divides from an integrations standpoint, and provide policy control over functional parts of an application. This provides a technological foundation for strategic partnerships that not only serve to tackle markets that may require legacy support, but actually deliver value at the same time (imagine that). Implementing a SaaS offering from a technical viewpoint can be divided, at the highest level, into two very broad categories: non-SOA and SOA.

(bigger)

Looking purely (from a 30,000 foot vantage point) at the positive attributes that SOA and non-SOA implementations bring to the table, in my opinion pursuing a SOA implementation does wonders for setting up a technological foundation that can be used to promote effective business strategies. Taking the non-SOA approach is great for getting to market quickly, but in the B2B space it can become increasingly cumbersome to support new initiatives and plans. To some degree, the market is starting to agree with this concept: SaaS offerings and consumer Web 2.0 apps expose a variety of interfaces as business expansion points. New SaaS implementations should seriously consider SOA as a foundational architecture if the company expects to encounter some of the business needs mentioned.

Do you agree that technology and architecture choices can significantly impact business strategy, or are they inherently uncoupled?

Uri Lederman of Konverge recently published an excellent post that maps the internal machinations of a non-SaaS ISV to those of a SaaS ISV. The key takeaway from that post is that the move from non-SaaS to SaaS is not only a revenue and model change, but also an operational change for ISVs. On various occassions, I’ve highlighted the fact that SaaS is a paradigm shift that requires buyin from within the organization rather than from just sales. Lederman identifies the impact in a more pointed fashion, specifying that operations and insuring proper transition impact customer churn.

When determining how to best map your current operations to a “saas-ified” one, the key analytic point is to evaluate whether a particular operational facet will negatively impact churn if left as-is. If, in fact, it will negatively impact churn you must determine how that operational facet can be morphed into something that either a.) provides recurring value to the customer or b.) reduces the probability that a negative experience results in a customer dropping your service. A good example is customer support (help desk). Traditionally, ISVs deployed software on-premise. This allowed for significant “wiggle room” on the part of support since uptime was two components: the quality and stability of the software (provided by the ISV) and the quality and stability of the infrastructure (responsibility of the customer). If an ISV making the move to SaaS doesn’t realize that both components (and therefore all burdens and accountability) are now their responsibility, they’re in a for a world of hurt. Help desk and customer support needs to be re-tuned from strictly a reactive entity to a proactive entity with reactive functions that strive to reduce customer loss. Don’t forget, customers pay recurring fees for recurring value. In the on-premise world, the customer has already paid for licenses and most likely for a year or more of support. This creates an upkeep scenario that is much less demanding than that required by SaaS since the downside is already dampened by a prepay amount.

Some ISVs try to create artificial downside by requiring very large SaaS “setup fees” in hopes of reducing the likelihood that a customer will leave as a result of poor service (if the customer has sunk enough money in the offering already, a psychological deterrent is established). Clearly, this is a sweeping generalization that doesn’t always apply but generally it is my opinion that these fees probably negatively affect that ISV’s adoption curve. Instead, that same ISV can take Lederman’s advice of recognizing that their operations need to be overhauled to support SaaS and rather than relying on artificial barriers to reduce attrition, they can rely on the mechanics of their “saas-ified” business.

Do you believe that ISVs can function in a business as usual fashion, or that they need to shift internal operations in addition to sales methodology?

Dear Readers,

We’ve established a LinkedIn group called SaaSBlogs. LinkedIn is a networking site for professionals and the purpose of this group is to extend the SaaSBlogs community and provide a place for further discussion and knowledge sharing amongst SaaS entusiasts.  We welcome you to join by following this link, and based on the comments seen here on SaaSBlogs, we’re sure we’ve got a lot of great conversation to look forward to.

 Thanks.

This post simply serves to provide a link to a post on another site, but I felt it very appropriate to shine the spotlight on a brilliant post by Ben Yoskovitz on Instigatorblog.com entitled ‘Lessons Learned Running A SaaS Business‘. While we tend to focus on the relative “newness” of SaaS, it’s always important to remember that there are people who have been approaching, solving, re-approaching, and re-solving the challenges associated with SaaS for some time now. Ben outlines some key points from a “looking back” perspective. Give it a good read, there are tons of gems throughout - especially for those building go-to-market strategies for SaaS products.

For those who don’t know who Malcolm McLean is, I’ll give a brief introduction. Malcolm McLean invented the modern shipping container: you know, the ones that come in on cargo ships, are craned onto trucks and trains, and that provide a standard for transporting goods worldwide. So why are his ideas important and what does it have to do with SaaS? I think we should all pay attention to the shipping industry and how he revolutionized it. SaaS and service oriented architectures have the potential to cause a change as profound as the one experienced by the transportation world in the 1950s.

Traditionally, software is notorious for capturing functionality and locking it away in an unsharable fashion. Any other piece of software interested in tapping into some other software’s functionality generally needed access to the source code or some non-standard programmer interface. This isn’t necessarily the fault of any one piece of software, but rather a problem of lack of basic agreement. Software lacked (and still somewhat lacks) protocols, well-defined modular architectures, and an economic model allowing for subscribed functionality that can compensate producers in a producer/consumer model.

In the shipping industry, McLean recognized some significant parallels: across transport mechanisms (trucks, trains, and ships) there was no efficient protocol (everything was break bulk) and economic models in transportation reflected a heavy penalty because of lack of disintermediation (someone had to interfere at each drop point to break down shipments). By introducing shipping containers and associated support infrastructure (crane structures, roll-offs) etc., we saw those issues alleviated. McLean broke the mold by recognizing that lack of standard produced inefficiency and not competitive advantage.  This is why these days you’ll see the same shipping container on the deck of a cargo ship, on the bed of a freight train, or on the back of a trailer heading down the interstate.

In the software space, we’re starting to recognize that lack of protocol, economic models, and isolated functionality are in fact hurting us. Service oriented architectures have shown that cross-technology communication and access to non-commodity functionality is possible from a technical standpoint, that applications can in fact be very modular (just look at the mashup craze), and that software as a service has introduced an early framework for monetizing this functionality between parties. Looking back at McLean and what the shipping industry is today, we should recognize that his work and ideas led to the ability to transport goods across the globe as efficiently as possible and that we have a similar duty in the software space.

Over time, do you expect that software space to become more protocol driven and more flexible in terms of functional composition, or have we reached our peak with respect to “functionality on tap”?

One of the much-touted benefits of single instance, multi-tenant SaaS is the ability for ISVs to respond to market demand and introduce new functionality and versions of their application to their entire customer base relatively easily. In other models, this was a nightmare and would actually dis-incentivize creativity and “staying ahead of the game.” This was understandable since the cost of distributing a new version was significant so it happened conspicuously as a major event in the lifecycle of your application. SaaS, however, encourages a continuous flow of new functionality to customers along with a “community feedback loop” to quickly absorb reactions and execute compensating actions based on that input.

One issue I have when people tout the aforementioned benefit is that it’s always from the R&D side of things. SaaS can also offer the same benefit from the pricing and business strategy side. This is true, however, only if the SaaS offering was built to support flexibility in that fashion. Let’s look at the antithesis of flexible business capabilities. Your company has architected and deployed the world’s greatest SaaS offering. It’s single instance, multi-tenant, scalable, and you can roll-out new functionality at the drop of a hat. Things are going smoothly until one day, the VP of Marketing comes in and says that their is a huge opportunity if we can reorganize the applications feature set to target certain verticals, and that the pricing strategy needs to move from monthly to quarterly in the existing segment in order for growth to continue. Oops, we didn’t think about that. The VP of Marketing has the authority to make that sort of strategy decision, but the app doesn’t care. It  was built with all the technological bells and whistles, but no one put thought into allowing the business folks in your company to independently make decisions without requiring R&D to intervene and make code changes. You’ve effectively architected an application that hampers the companies ability to “think on it’s feet” and make either reactive or proactive moves.

The key when building a SaaS offering is recognizing that it is the center of interaction and discussion at your company. How responsibilities are divided up in your organization and how the different teams and departments interact with it must come up in conversations related to implementation. You should ask yourself questions like:

1. Can we roll-out new functionality or bug fixes easily?
2. Can sales & marketing reorganize how the application is sold or marketed without intervention from R&D?
3. Can support teams gain access to normally sensitive or restricted information (such as execution logs, etc.)?

The more you can integrate your business’ concerns into your implementation decisions, the more agile and responsive you can make your business.

Do you feel that agility is under-appreciated and/or under-utilized in the SaaS model?

Eugenio Pace from Microsoft’s SaaS Architecture Team published a great webcast describing the potential relationship between ISVs and hosters and how a SaaS platform fits in. It’s worth the watch. One of the major takeaways from the video is that a good platform marginalizes an ISVs efforts involving things like multi-tenancy, onboarding of new customers, monetization, operations, revenue modeling, etc. but still gives an ISV autonomy, complete control over their offerings core definition and the interactions their customers have with the application. It’s a lengthy 30 minute video, but well worth the watch.

If you watched the video, how receptive are you to the ideas Eugenio outlined?