Can the Fortune 500 Achieve Efficiency through Intra-enterprise SaaS?

Jul 4, 2007 by Sinclair Schuller

SaaS is generally approached from the standpoint that a SaaS provider will write an application and sell it as a service to other businesses. This provides the many well known business driver benefits to those who use SaaS. Additionally, it is also well understood that the provider generates certain efficiencies via the centralization of the technical burden associated with the application. Is there another realm of SaaS applicability, however? In my opinion, absolutely!

Whenever I gauge the ‘size’ of a SaaS provider, I look to see how many subscribers they support – not customers, but actual individual users. Many SaaS providers are in the 5,000 user to 20,000 user range across hundreds of customers. While these numbers are not small, some Fortune 500 companies have more employees than this, spread across numerous subsidiaries. Furthermore, the Fortune 500 write a considerable amount of software for use by their employees, with some software (such as HR/Expense Reporting/Time Management apps) used by virtually every employee. Can SaaS help organize this scenario? From the technical/architectural standpoint – yes it can. If an enterprise were to write software for their employees & subsidiaries with a single instance, multi-tenant model in mind, they would undoubtedly be able to centralize and organize administration while being able to distribute functionality. That’s powerful and efficient.

Have you worked on any intra-enterprise SaaS applications? Who were your tenants – subsidiaries or departments? Did IT realize efficiencies through the model?

 PS: If you are in the U.S., have a happy and safe 4th!

 

read more

Reaching the SMB – Can Telcos Lead the Charge?

Jun 5, 2007 by Sinclair Schuller

A few months back I wrote this post which discussed trying to get SaaS offerings into the hands of SMBs.  The question was a.) Would traditional channels (e.g. VARs, stores, etc.) play a role and b.) what new channels would develop to push SaaS out to the SMB. Well, a combination of some conversations with telcos as well as this article over at Tech Target helped highlight an answer to b.)

The article discusses the current desire for some telcos to push SaaS services to their business customers, providing the telco a lucrative way to tap into the SaaS space and experience a new revenue stream. But will it be an important channel? In my opinion, absolutely. Telcos already have the SMBs ear: SMBs purchase phone, internet, and other services from telco providers. Practically each and every SMB uses a Telco. SaaS really fits the telco product mix well, augmenting their offering and exposing SMBs (and micro-businesses, for that matter) to our beloved SaaS distribution model. Could telcos be the answer to pushing the model deep into customer territory? I think it has a good shot. Any thoughts? Do you see another channel taking the lead or will telcos not understand the dynamics well enough to capitalize?

 

read more

Explaining SaaS Trust and SaaS Platforms Metaphorically

Apr 23, 2007 by Sinclair Schuller

Although SaaS is in and of itself of a unique and powerful model of software delivery, there is much to learn from industry’s that have produced either perfect or imperfect parallels. When I say ‘perfect’ I mean one with a distribution concept that provides a metaphor for SaaS, while ‘imperfect’ is more akin to an industry that has a similar psyche or has equivalent emotional requirements. During SaaSCon, I heard many metaphors and similes tossed about to help clarify what various aspects of SaaS are. Two particularly caught my attention – one was provided by Treb Ryan, CEO of OpSource, while the other came up during the keynote panel I participated in.

Treb had used the banking simile (which has been used before, but I think it highlights the psychological end user/provider nuances quite well) as an imperfect parallel, likening the psychological and trust issues experienced by SaaS providers to those experienced by the banking industry in its early days. He asked the question (I’m paraphrasing) “Do you feel safer with your money under your mattress or in the bank?” Granted, most of us would answer “in the bank”. However, at one time many people felt that putting money in the bank was unsafe – after all, who better to trust with your money than yourself? Someone could burglarize the bank, your money is mixed in with everyone else’s, etc. Once the populous got over the “trust” issues, a complete reversal happened. People recognized that money in the bank was far safer than keeping it at home – and so was born the massive industry we call banking. SaaS poses many of the same trust and security questions, and very much like banking, will prove to be the better model. Now, I’m not saying that “since it happened over there, it’ll happen over here” but it is easy to see that trust issues are by no means insurmountable, and arguably, if trust can be established with money and other liquid equity, I’m sure it can be established with software and data.

During the keynote panel, a question was asked by an audience member that I ended up fielding (again, paraphrased) – “Do SaaS platforms parallel the telco industry where value is controlled across the entire stack by the telco, or is it closer to the electrical grid where value is at the appliance level, which taps into the distributed power.” The question posed a perfect parallel because of the nature of electricity distribution. My response to it was that the electrical grid provides the best parallel for SaaS platforms – SaaS platforms are responsible for providing the foundational aspects of service delivery and management (i.e. “power grid”) while each application defines the actual value to the end user (where an application is much like an appliance). For example, if I toast bread, my derived value, although powered by electricity, is provided by the toaster oven. When a user uses a SaaS application built on a platform like SaaSGrid, the end user value is provided by the application. So where does the SaaS platform fit in? Well, your toaster comes with a power cord – an interface that encapsulates certain expectation. That power cord and any corresponding regulatory mechanics tap into the electrical delivery grid to make toasting bread possible. With respect to telco’s, value (in present form) is generally introduced by the telco and no-one else. Cell networks tend to be closed, and new functionality is introduced by the telco itself. That parallel is not valid – at least not with SaaSGrid; a platform’s goals should not be to monolithically provide value to the end user, but rather to provide all necessary delivery mechanics to the SaaS provider. SaaS providers – the appliance manufacturer’s – know what their respective customer’s want, and can deliver appropriately. The most important thing to realize in all of this is that most toaster’s do not come with their own power sources;-)

read more

The Complexity of Monetizing SaaS Application Usage

Apr 4, 2007 by Sinclair Schuller

I’ve been following a series of blog posts by Lars Fløe Nielsen, Michel Baladi and some other folks from Microsoft, Sitecore and other firms. The posts follow a proof-of-concept project established by the firms to investigate how a “SaaS Hosting Platform”, or SHP, ought to look like. I appreciate the effort that has gone into this, and it really hones in on what is important to what parties in a SaaS ecosystem (ISV, hoster, end user, etc.) One particular post that caught my eye was this one. In it, Nielsen describes metering and billing constructs that would be handled by the SHP, as coordinated by the ISV during the definition phase of monetizing the application.

This post is interesting simply because it shows how complicated SaaS monetization, metering and billing can be. Some applications will have “simplistic” scenarios of a flat monthly rate with little variability. Others will need transactional charge capabilities such as a per e-mail or per help ticket opened, or the ability to fluctuate periodic recurring rates based on feature packages. Even still, some applications may need to cut “non-standard” plan agreements with certain customers to close a large sale. Even still – marketing may have the need to institute temporary discounting or model changes, while preserving the original monetization base. All of this and we’ve only discussed defining monetization – metering and billing is a whole other ball game. Metering will generally follow the complexity level defined by the monetization definitions. Obviously, if a SaaS provider is building an app from the ground up. This is where we see plenty of immediate value from the SHP concept – if this can be provided as a part of an out of box experience by a SaaS platform, an ISV can build revenue models that are very unique and specific to their needs. Nielsen’s SHP metering and billing revolves around a standardized definition language of sorts, which is exactly the way to go.

Good SaaS platforms will give the flexibility required to achieve unique and complicated monetization definitions and match that with efficient metering capabilities. Have you built or are you building a SaaS application with a very unique way to charge that you wouldn’t mind commenting about? Have you as an end user or consultant encountered any awkward yet impressively tuned usage models? I’d love to hear about them!

read more

For Your Consumption: Article on Datamation

Mar 16, 2007 by Sinclair Schuller

Just a quick note: Datamation recently invited me to write an article for their website.  The article, entitled Repealing the SaaS Tax, was published a few days ago and it focuses on SaaS enablement, and more specifically, enablement through platforms, so check it out and let me know what you think!

PS: Sorry for the late notice

read more

Does the SaaS Ecosystem Concept Lean Toward Natural Oligopoly?

Mar 2, 2007 by Sinclair Schuller

Rare is the day where using the phrase “SaaS Platform” doesn’t invoke the usage of “SaaS Ecosystem.” Heck, it even found its way to the title of the keynote panel I’m part of at April’s SaaSCon: Understanding SaaS Platforms and Ecosystems. The reason for this “two peas in a pod” syndrome is pretty easy to explain: SaaS platforms aggregate vendors, offerings, and end users in a pseudo-closed system which creates a huge amount of long-term value potential in exercising this network of relationships. This network is what we call an ecosystem and the value that can be created by commanding successful relationships is important to all parties involved.

I was discussing the future ecosystem landscape with someone, and inevitably the question of “How many ecosystems do you think will exist in a few years?” came up. Trying to quantify something like that this early definitely requires painting with broad strokes, but looking at the dynamics my answer is that a handful of ecosystems – a veritable oligopoly – will account for almost all ecosystem participants. In this scenario the oligopoly would not be forced or created through regulation, but would in fact be a natural oligopoly – the result of convergence due to economic factors. Why? Because ecosystems are networks.

A SaaS ecosystem’s value is very much defined by the size of its network, which is composed of three types of members: vendors, applications, and users. Looking at the trivial case, an ecosystem with zero participants of any type is valueless, as is the case of an ecosystem consisting only of suppliers and supply. As a mix of members from the three aforementioned groups start to enter a specific ecosystem, the value of the ecosystem increases. End users have the ability to gain value from relationships defined by participating vendors or deployed applications, vendors themselves can experience synergies by creating relationships with other vendors in the ecosystem. What this does is create a positive feedback loop.

If there are no costly or threatening barriers to joining an ecosystem, non-participants will measure the value of the ecosystem by the number of links it offers – the larger the network, the more valuable (i.e. Metcalfe’s Law). This is the reason why instant messaging, for example, is a natural oligopoly. If you had to choose a messaging service, what would you choose GTalk or AOL Instant Messenger? If you chose GTalk, you probably won’t be chatting with too many people. With AIM, you’re almost guaranteed to be able to chat with anyone you want. Any growth within the instant messaging realm generally gets absorbed by the few players that dominate the market because people want to join the networks that their friends are on. Ecosystems, by nature, are capable of harnessing the same network effect. A largely fragmented system with dozens or hundreds of ecosystems presents very little value to any participant. A few ecosystems that aggregate huge numbers of participants and value, however, benefits most everyone (as long as the oligopoly remains as such, offering market choice and fostering continued competition).

Right now, we’re very early in terms of the SaaS platform and ecosystem space, so I’ll be brave and attempt to be an oracle. In these early stages, value focus will not be on the value of the ecosystem; participants will choose platforms that offer the most immediate value in terms of technical merit, application offerings, etc. As the participant numbers of the early platforms and ecosystems grow, value focus will shift to the network value of each ecosystem. A market shake-out will most likely follow due to the rapid growth of some ecosystems, leaving that golden handful as clear leaders and many, many participants that can benefit from the huge amount of value that these networks can provide them.

Do you agree with this notion, or do you see a situation where many more ecosystems exist? If this was the scenario, do you think the aggregation of value is worth having an oligopoly?

read more