Software as a Service (SaaS)

For the end-user, the UI is the application

2008-05-14T07:07:36-07:00

With his postings, Bob Krygowski highlighted many important aspects of Software as a Service, as in his The Other “S” in SaaS - Service Complementing Bob’s blogs, with this posting I will start discussing about the first “S” in SasS – Software.

I am seeing that frequently the terms SaaS, Rich Internet Applications (RIA) and AJAX are used interchangeably, as if they were the same thing. They are not. SaaS applications should have as rich a user interface as possible of course, however not all RIA are AJAX and SaaS is not the exclusive business and deployment model of RIA. Comprehensiveness, agility, flexibility, modularity, intuitiveness, ease of use, maintenance and administration are all very important requirements for business applications. Many of these attributes are invisible to the end-users of business applications. They --- rightfully, I think --- don’t care or just take these characteristics for granted. To them, the first order priority is to perform their jobs as effectively and productively as possible and one of the most important means they have to do so is by using the application’s functionality through its user interface. Ditto: For the end-users, the UI is the application.

So, what is the best user interface for SaaS applications? Business applications must have the user interface(s) that fit the needs of the end-users. It is common for power users to require very rich desktop-like user interfaces with Windows look and feel (L&F), highly responsive and with desktop integration (ie. Outlook’s metaphor has gained tremendous acceptance and more often than not end-users demand it as their L&F of choice). On the other hand, a traditional web-style (block-oriented) user interface with some Ajax may be more appropriate for occasional end-users. Quite frequently any given application must meet the needs of these two types of end-users!

How to address this dilemma? With robust, field proven SOA-based development and deployment products and tools that include support for a broad range of user interfaces, reusability of a single code-base, abstraction from basic technologies to facilitate maintenance, and one development language for data management, business and most user interface logic to keep the costs low and the developer’s productivity high.

OpenEdge addresses these requirements with flying colors. And proof of OpenEdge’s versatility and comprehensiveness, is its leadership position in the SaaS marketplace with a vast catalog of actual commercial SaaS business applications in production, as discussed in Progress-ing Towards ERP On-Demand.

The SaaS business model makes it easy for businesses to rapidly subscribe and use business applications, and makes it easy as well to switch away from those offerings that don’t suit the needs of the end-users!

Therefore, regarding the user interface of SaaS applications do not get carried away with market hype and choose the UI to meet the needs of the end-users. Architect the applications using SOA/OERA principles and OpenEdge will give you unmatched flexibility to use any or multiple UIs at once: (D)HTML, Ajax, Windows desktop GUI, .NET, Java, Adobe Flex, --- to name just a few --- and using one business logic code-base operating in OpenEdge application servers running on UNIX, Linux or Microsoft. Choice is good and OpenEdge gives you the power to choose. Do not settle for less.

In future postings I am planning to discuss pros and cons of user interface options. I'd love to hear from you: What user interface(s) are you using, or planning to use with your SaaS applications?

Development vs. Delivery Platforms for SaaS

2008-05-01T08:36:20-07:00

A new study by McKinsey & Company published this week talks up the impending battle between SaaS development and SaaS delivery platforms.

The SaaS development platform is essentially a turnkey application development platform, including runtime, database, hosting, development tools, common UI, hosting, etc. Companies in this space are Force.com, Bungee Labs, Longjump, Coghead, and likely many others to come.

The SaaS delivery platform combines all the element necessary to deploy and administer a SaaS offering, and solve many of the ornery and expensive elements like billing and metering across multiple offerings, single sign-on, service provisioning, service monitoring, infrastructure scalability, application integration, etc. This is a great option for APs who have made a commitment and investment in their application and don't want to re-write. Some players in the industry today are OpSource, Amazon (EC2 and S3) although this is not a complete offering, and likely to be others as the hosting providers in the market realize that simple Linux or Microsoft hosting isn't enough and they move to offer more valuable and integrated services.

Assuming for the moment that you see the market evolving in this way as well, what path would you take? Do you see something different?

The Other "S" in SaaS - Service

2008-04-28T10:58:15-07:00

I suppose it makes sense that much of the discussion you read in blogs, datasheets, websites, and even from the analyst community about SaaS almost exclusively talks about it as a technology, and gives little air time to the other "S" in the SaaS acronym - the service - and what it means to sell a service as well as the use of an application.

When we talk to ISVs about taking advantage of the growth opportunities related to SaaS, what often gets lost is what it takes to be service oriented - as a company. Most get it that the service needs to be available in order to generate revenue, but often times that's where it ends. In truth, that's where it starts.

• The service becomes the product. Treat service problems with the same energy and priority as bugs in the source code. Many successful service companies that I've been fortunate enough to be part of in my past run daily service quality meetings, and not only review the up/down status of the equipment, but also review call volume, call severity, the nature of the call (technical vs. non-technical), billing issues, etc. While service issues can be categorized and prioritized for resolution, speed of resolution and how you handle a customer is even more important. Make sure you can talk to a human within a reasonable period time, and not put them into an endless support queue. I personally don't believe you can get away with different levels of support based on what the customer pays. Sure, it's possible to guide users to help themselves through online help, but don't make that the only option. It's also important to remember that the user is often a buyer or influencer into the decision making process, so be aware. I would bet that for most product companies, the one who made the purchase decision almost never calls the help desk, putting the support team on stage at all times.

• Accountability. Executives should establish service quality goals and tie compensation to those goals. Nothing motivates like cash, and if a company is truly serious about delivering a quality service, establish clear goals regarding service quality, communicate them throughout the organization, measure regularly, and reward for achieving and penalize when goals are not met.

• Transparency. I've seen some great examples of companies with SaaS offerings who give you a pretty unique view of how they're performing. Salesforce.com for example publishes their availability status on their customer portal, as well as historic availability metrics so you can judge for yourself whether their performance will meet your needs. Also think about the value you want your customers to place on your service, if you want to be the mission-critical guy to them, then you need to give them what they need to feel comfortable at a moments' notice. Yes, sometimes it hurts when things aren't going well, but it's healthier in the long run for your customer and for you.

• Communication. I touched on it before, but communication within the organization is critical, not just for SaaS companies, but when trying to put the square peg of a service business into the round hole of a product company. Transforming the identity of a company is hard work, and communicating effectively from the beginning is critical.

• Simplicity. Making it easy to do business with you is always a good start. For many ISVs, ordering services, ordering additional services, canceling services, reviewing and understanding the bill, speaking to a human when you have questions, etc., are all so often overlooked as part of the customer experience. But with a services model, thoughtful consideration should be given to the various touch points the customer may use to experience your company – outside of the application itself – and take advantage of those opportunities to provide easy and excellent levels of service. I sometimes equate this to a new restaurant, the kinks haven't been worked out yet, but as long as the food is good and the place is clean, you'll likely be given a second chance.

• Performance counts. Gone are the days that you can wash your hands of network latency problems, slow page load times, etc. Business buyers are consumers too, and their biases towards crappy and excellent service come to work with them. Think about how the service will look from their perspective.

• Capacity Planning and Scalability. Without taking a completely purist view of SaaS, most ISVs with SaaS offerings provide the service delivery infrastructure as part of the overall value proposition. Remember, though, by taking on that responsibility, you're now responsible for knowing your customer well enough to have enough capacity – of everything you offer – on hand to meet their needs, and for you to generate revenue.

• Relationships. Whether you price based on the number of users, volume of data or transactions, or some other metric, the relationship you have with your customer has to be managed. This is not to say you have to dedicate a resource on a 1:1 basis, but thinking less in terms of a one-time sale and more in terms of a long-term, growth-oriented relationship is a higher level of service most product oriented companies don't practice today, and which requires commitment to get right.

• Service Level Agreements. I bet that in the past the closest most ISVs came to offering a service level guarantee was their warranty, which we all know isn't worth that much. But with a service, the trend is heading in the direction of having to put some real guarantees behind the quality of the service you provide, guarantees that are backed up by cash payments or credits if you fail to meet the quality metrics you agree to.

• Stuff that probably shouldn't be your problem, now it is. I spent quite a few years with companies that offered managed services, and in my case they were hosting, security, and networking – all pretty important in a SaaS based business – and I always found myself in the middle of what we thought was the customers problem. Blocked email servers, inefficient LAN routing, application configuration problems. Playing the role of a service provider, especially one that takes a turnkey approach to delivering an application service, be prepared to address a wide range of topics considered to be part of the application delivery chain, regardless of whether or not you had or have anything to do with it.

• Account Management versus Sales or Business Development. Instilling a commitment to building a healthy, ongoing service relationship, with financial incentives from continued growth, is another important transition to a services mentality for the company. For the ISV, much of the financial growth in the account comes from increased usage of the service, which means that you have to pay closer attention to the customer throughout their lifecycle as a customer, and not just until the application has been handed over.

• Change things up. While there are a lot things to consider as you adopt a more services mentality within the company, one positive aspect is that you are constantly getting feedback from your customers, and have the ability to tinker with the service to make it better. The closer relationship you've built will therefore help you be more responsive to your customers needs versus using a patch or bug fix release every month to six months to fix issues.

What do you think? How have you made a transition to a services model from a product model? Any interesting experiences?

Any Good Channel Models for SaaS?

2008-04-22T10:56:13-07:00

While I'me not sure I would call it a dirty little secret, the lack of a solid channel model for ISVs who make an investment in taking a SaaS offering to market is conspicuously absent.

Many are trying, the current influx of Platform-as-a-Service (PaaS) vendors is one such example, vendors like Force.com (www.force.com), Boomi (www.boomi.com), Longjump (www.longjump.com), and the list goes on and on. PaaS vendors solve a very thorny problem, particularly for start-ups who have the benefit of a blank canvass upon which to work.

But where do you go from there? You've made a decision to build on a platform that gives you the infrastructure you need to get started and run a service, but without any customers who really cares what platform it's run on.

What role should the PaaS vendor play in helping companies with SaaS offerings find customers, if any? You'd think that in exchange for the virtual platform lock-in they would do more to help their customers be successful through lead management, market awareness, mashup or composite application support, etc.

What about other channel models or simply a path to the end customer - the one who pays the bill?

The direct sales model? Depends on the solution, but generally too slow and expensive for the long term, and doesn't generate the kind of scale required (with some notable exceptions). However, much of the B2B side of SaaS is still sold this way.
Systems Integrators? Perhaps. Microsoft will undoubtedly have some success selling Exchange and Sharepoint through the SI and hosting community because the administration and customization side of Sharepoint, and a cottage industry has sprung up around Salesforce.com to help with process design and implementation, but nothing too dramatic.
Partnerships? Likely one of the most compelling options, but one that has yet to gel in any significant way. Imagine partners joining forces and resources to address similar target markets with complementary offerings? Sure, lots of details to work out, but might be a great option to explore.

What else is there? Any thoughts or great examples?

Welcome to the SaaS blog

2008-03-10T06:23:43-07:00

Welcome to the Software as a Service (SaaS) blog sponsored by Progress Software.