1. SaaS will continue to grow in acceptance and prevalence in the marketplace but – the term itself will fade in favor of “Cloud (insert your term).” There is no end of analysts predicting the continued growth in 2010 of SaaS as a business model for software vendors and a positive direction for software users. That part of the prediction is about as safe as predicting rain will come to Seattle sometime next year. But – we’re not going to call it SaaS much anymore? Is all that marketing ink going to disappear? No. But the truth is we get tired of hearing the same old tune everyday and it starts to become little more than background hummmm. Everything “Cloud” is ascending and marketing loves it because it is by definition a nebulous, foggy term that can be floated for nearly any purpose. I could just as easily say the same thing about the time worn acronym Service Oriented Architecture (SOA). At the heart of all well-designed services is a SOA strategy – but we don’t really talk about it explicitly. Marketing has hit that nail for over 10 years and still very few know what we’re talking about. The same is true of SaaS. Discuss the term and we get tied up in preconceived arguments about security, lock-in, lifetime costs, and multi-tenancy without discussing the business case for vendors and users. Next year we’ll be shedding those arguments and just selling mature services without acronyms. And to add one more log to the fire that will lower the prominence of the term “Software as a Service” – vendors of virtualized infrastructure have already hit commodity pricing thanks to Microsoft’s Azure and Amazon’s offering – the only place for them to go is to add application suites to their “cloud.”
2. Real business value in SaaS will continue to improve, be better understood and measured more explicitly. There is a growing understanding of the difference between an ASP implementation of a standard premise-based application and a service that designed for the delivery medium that is embodied in SaaS. It is much more than technology or an offset of costs for infrastructure and resources. That said, the metrics on both the vendor side and end-user side of the SaaS equation need more clarity and uniform acceptance. As a buyer of a SaaS offering, I shouldn’t care if it has been adopted by hundreds or millions of users. What matters is who is using it successfully and what is their context? If I am going to base a critical part of my business on a SaaS offering, I need to understand if the lifetime value of customers is substantially greater than the cost of customer acquisition. I need to have confidence that the adoption of the service is higher than abandonment. I need to know the service will have enough value to continue. Having that confidence is a product of a conversation between the SaaS vendor and their customers/end-users. It takes some real thinking on the part of the vendor to engage in that level of collaboration – but we will continue to see the most successful services providing a model of this behavior and inspire others to do likewise.
3. Service ecosystems will rise. Best case SaaS should be designed to meet the market embodied in the Long Tail. As we and others have said many times, the economics of SaaS and efficiencies of modern development cannot really be leveraged without a good-sized market. You can often reach sufficient market size by targeting your service to the second and third tier markets in a vertical but the time required to reach positive cash flow in SaaS can still cause many problems. Whether a specific service can be sold to a wider market or not then – it is wise to consider an ecosystem approach and I believe many will in the coming year. Salesforce and Google both exploit their ecosystems to bring a broad range of services together on their platforms and as was mentioned in our first point, cloud infrastructure vendors are heading in the same direction. In verticals, I can imagine a focused service teaming up with a general operations package for instance – especially one that could be pre-configured and integrated to the vertical application providing a “suite” for users. This can give users the benefits of single sign-on, data sharing, perhaps a lower total cost (assuming the vendors recognize the value in packaging joint services) and a “desktop” for most tasks they do everyday. In fact, in the long run, I don’t expect to see many “stand alone” services – it just doesn’t make sense for the users or the vendors. We will see a lot more applications “joining forces” strategically or being acquired in the next year by integrating, combining user data pools or through “Mash-Ups.”
4. New services will focus less on “doing it all from day one” and more on their roadmap. In the “brave new era” of SaaS, one of the big impediments of developing a service was all the decisions you had to make and all the business operational aspects you had to have a handle on to arrive at requirements and start development. Many entrepreneurs felt they were being asked to either start with the equivalent of the original Wright Flyer or with a development burden so large they could never reach a positive cash flow with a reasonable investment. Now however, there is a wide array of mature, tested services that can be easily integrated into a service product to provide standard approaches to operations, integration, sales, and many other business and technical requirements. With an extensible architecture, there is a great value in picking “best of breed” services to do the “dirty work” while focusing custom development work efficiently on the real value proposition for a service. The time to market and up front investment decrease dramatically and the risk of running out of cash on a reasonable investment is contained. As none other than one of the leading investment groups has proclaimed, “Less is more!” And rather than worry about “lock in” – thoughtful entrepreneurs will realize at the point in the road where the cost of the integrated services begins to be a part of overhead that is worth investing some development time in – current development practices can allow extensions to the application without an expensive rewrite.
5. Integration requirements will drive standards for service-based communication and interaction. If cloud “ecosystems” are going to rise, if online services are really going to dominate the market for innovative products in the near term, standards for integration and service-to-service interaction need to be recognized and grow dramatically. Despite the continuing whines of a few holdouts – no serious vendor of online services should be considering parallel deployments – both on site and across the Internet. Developing a product that can address both markets eventually becomes “SoSaaS” – a product so hobbled by its split identity it cannot truly leverage the value of either delivery model. Instead, with an extensible Service-Oriented Architecture (SOA), open APIs and standard integration tools, online services will offer ways to leverage local data, applications, and other online services in ways that are in the end much cheaper and more reliable than traditional custom integration services. This doesn’t mean SaaS vendors won’t offer on-site applications – but in many cases those applications will be hubs for addressing local integration needs and compliance issues.