SaaS Development

It seems that when software companies are striving for growth, they tend to equate spending big money with the probability of future success. A good case in point being the massive investments some software companies are making to develop Software-as-a-Service (SaaS) products. Based on a bit of research, it seems that the average time frame from build to launch for a new SaaS product is 12-18 months and the average cost is over USD$1,000,000.

In a hostile economy where users are demanding to achieve more with less, the SaaS model is certainly in greater demand. There's no doubt the move to SaaS is required for most software companies and those software companies that can embrace the new SaaS paradigm are being validated by their results in the marketplace . (Article) Although you may still find a few large on-premise companies that have not figured out how to maintain their current revenues under a SaaS model.

Agile project management or "Agile software development" appears to be the primary methodology for building and maintaining SaaS offerings as it brings greater clarity, transparency, and control to the software development project. And according to SaaS University producer Rick Chapman of Softletter, 68% of SaaS companies are using Agile as of 2008. (Article by Rally Software) Presumably, coupled with some form of Extreme Programming (XP) this leads to faster development and greater project success.

If you look at the 10 reasons why early stage companies fail from a VC perspective, the main reason is CAPITAL.

So why are software companies wasting 12-18 months and over USD$1,000,000 to build their SaaS products when cheaper and faster alternatives seem to be abound?

It's possible that the numbers are skewed because heavily backed venture companies, such as Salesforce.com with its $200M original seed money, or large on-premise software companies are either trying to take their full feature products with 10 years of development history to market all in one shot, or they are acquiring successful SaaS startups and paying for the potential. Others suggest the on-premise companies don't have the SaaS business and technical expertise yet still resist getting educated or getting help. For BigCo positions see articles on Sage, and SAP and Lawson).

So What Does It Really Take to Build SaaS Products?

To do the math, one can figure that even without a SaaS development platform (such as Force.com, SaaSGrid, Wavemaker, Servoy, etc) a simple SaaS product similar in functionality to Linkedin.com or Facebook or MySpace when they first launched, could be built within 9 months leveraging an Agile team with 1 ScrumMaster, 1 Product Owner, 1 architect, 4 developers, and 2 QA. Let's say that's 9 total full time people. 9 people for 9 months. Even if those were full salaried well paid US based resources the numbers seems skewed.

In an effort to reduce costs, many SaaS companies are outsourcing their application development and testing to Asia, mostly to India. The challenge with outsourcing high collaboration, Agile SaaS development projects to Asia is the distance, time zone difference, and communication challenges. All of these factors contribute to higher overhead and lower productivity than originally expected.

It's not hard to find examples of offshore software projects that have failed, and mostly due to iterative development models, with inexperienced junior developers, and a lack of clear communications. But many simply focus on the HOURLY RATE rather than PRODUCTIVITY or TOTAL COST OF ENGAGEMENT.

Perhaps the high costs of SaaS product development can be attributed in part to the failures and challenges of offshore that are reducing the productivity, extending the total development time and increasing the costs. So why bother looking at $25/hr developers In Asia if the probability of delay or failure is close to 70%? Are there no alternatives?

Latin America has been noted within the last 5 years as a great place to outsource by leading analysts. Companies such as Scio Consulting in Mexico work on central time, with offices less than 4 hrs by flight from most US cities, specialize in SaaS enablement; porting existing on-premise software to the web. They suggest most SaaS projects range from 4-6 months, between $50k-$300K using either the .NET, Java, or LAMP stack. Granted they are proposing to use SaaS platforms for rapid development but certainly the investment difference makes you curious. Choosing an offshore or outsourcing partner is a difficult one that should be done with care.

When investigating SaaS business models, one consistent message comes across: A new level of agility and responsiveness is required. This article truly sums it up.

"A lot has been said about what Software as a Service is and is not - and we've been part of the noise. I really feel however there is something bigger going on. There is a tsunami coming and SaaS is only one of many waves.
People have said SaaS is:

* A delivery method enabled by the spread of low cost broadband
* A technical architecture (multitenancy) that provides higher efficiency and lower costs (in the best implementations anyway)
* A business model led by direct responsibility for service to end-users
* An alternative to the traditional capital investment model of software licensing
* A low cost way to take advantage of applications and services for SMBs
* Gaining acceptance in enterprise business
* A potentially disruptive business model that could end the dominance of traditional software vendors
* An opportunity that allows new players to "level the field" against intrenched industry leaders
* A flash in the pan that will eventually morph into some other even cooler marketing-led hype.

I would say all of these things are true - and more - or less. In another way however, these observations miss the point. An illustration might help:

In the "traditional software vendor" business model, the buyer is the ultimate customer. If the buyer is a company - no matter how large or small - the buyer is the filter between the people who use the application and the vendor. If you add in a sales or service channel, a secondary source, the relationship with end-users becomes even more tenuous for software vendors.

Think about that.

Most buyers don't want to be constantly involved with their vendors and the bigger the company the buyer represents, the more that is true. So, if a vendor relationship comes down to a purchase and maybe a license renewal every two or three years - fine. Near renewal time, there are opportunities to push for new features, fix nagging problems, and maybe switch to a new application. Just as often, renewal periods are time to leverage the "choice" to change to get better terms. Even more importantly - renewals are generally concurrent with new product versions so that vendor sales and buyer interactions are orchestrated. Marketing and sales insure that the conversation at renewal time is more about the "new features in this version" rather than the new features needed by specific groups of end-users.

So how is SaaS different?

In the SaaS business model, the "wall" provided by the buyers between end-users and the software vendor is nearly eliminated. SaaS is a service relationship and the vendor is directly responsible for "user experience." The buyer enables subscription or transaction payments on an expense basis and turns the operational relationship over to the software vendor. Software-delivered-as-a-Service. Oh....

Now the daily concerns about why the application doesn't quite meet expectations can go directly from the end-user to the vendor and in most cases - since this is outsourcing in reality - the buyer expects nothing less. Put that beside the truth that high renewals are key to survival as a vendor in a SaaS business and you begin to see something important. The software vendor - to be successful - needs to consider a new way of operating.

Enter "agile" product development and "the agile business architecture" stage left.

The same wave that is gradually taking hold in software development is now being adapted to service-based business operations. Except - we haven't really acknowledged it yet. How does a SaaS vendor insure retention and stay ahead of competition in the dynamic world of the Internet? By eliminating the artificial renewal period version change, proactively engaging with end-users (support), mining the business intelligence that is now in their hands (aggregated usage), becoming the face of a service instead of a label on an install CD (social media and marketing). By co-opting competition and finding ways for them to join in (APIs and marketplaces). By eliminating long design cycles in favor of a system that can embrace continual, targeted improvement and that responds to a changing landscape. By becoming truly Agile for the same reasons the idea has taken hold in development.

The truth is that the problems that became apparent when outsourcing first hit customer service in consumer goods are just as important when an application becomes a service. A service provider who ignores the end-user's context, that can only respond when you have reached the head of the queue and then only read from user manuals isn't going to win at SaaS. Creating more hurdles for the end-user to jump over so you have less interruptions during the design cycle doesn't make you more agile. Being Agile is about flexibility, response to change, and finally responsibility for success at a very individual level.

In a world where Moore's Law is an accepted reality, where even GM has to downsize to become more competitive - we also have to accept that change is now the constant and we have to rethink how we organize and work. The principles behind the Agile Manifesto are being applied to successful business more and more every day. Because we - at Scio - believe this is a critical subject you can expect more about agile business architecture and for SaaS vendors - how it can be enabled in the application itself - in the future."

Article by Michael Dunham on Haut Tec

The Need

For software companies considering investing, acquiring or developing SaaS applications, an independent judgment on the technical validity of an application can decrease the time to market, and reduce the risks of project failure. Technical assessments can suggest appropriate development platforms and architectures, highlight potential problems, correct oversights and validate costs and schedules, which are too often underestimated.

The Solution

You may require a SaaS Technical Assessments for on-demand and SaaS applications to perform an in-depth study of your application and its supporting infrastructure by a senior development team. A comprehensive assessment should cover all aspects that will affect the performance, scalability, manageability and security of the application, including any of the following areas:

* Application Architecture
* Application Security
* Tenancy Model
* Provisioning Model
* Integration Capabilities
* Database Design
* Infrastructure Architecture
* Usability & Accessibility
* Contingency Processes
* Development Practices

Are you thinking about introducing a SaaS offering to the market? According to Gartner, "worldwide software-as a service (SaaS) revenue in the enterprise application market is on pace to surpass $6.8 billion in 2008, a 27 percent increase from 2007%..." and SaaS "%...is forecast to have a compound annual growth rate of 22.1% through 2011%... with SaaS revenue reaching $14.8 billion in 2012." It is expected that a third of all software vendors will have SaaS offerings within the next 3 years, and that 40% of all new applications will be built as SaaS. This means that if you are not on the SaaS platform, your competition soon might be.

But as a traditional software company, migrating your existing technology and revenue model to SaaS can be complex and, without best practices, can be costly or even detrimental to your business. Nearly every aspect of operating a SaaS model is different from that of a traditional software business. So, how do you make the decision of whether SaaS is right for your company? And if it is, how do you build a roadmap to help you get there successfully?

Many have considered working with a SaaS Consultant; a guru, go-to-market-SaaS-expert, if you will. However, when seeking consulting to help you start or improve a SaaS business, you must first consider a few criteria:

Determine where you are at and where you need help
Do you have budget to pay for a consultant, which can help you get the results you need, faster, or will you have to develop your own marketing requirements document (MRD) or product requirement document (PRD)?
Do you have the technical or domain expertise to work on your own?
Clearly SaaS is different from ASP and traditional on-premise software models. You will need to perform an in-depth analysis of the following aspects of your business:

* Competitive Positioning
* Pricing Model and Strategies
* Market Potential
* Technology and Architecture
* Implications
* Estimated Costs
* Required Business Functionality
* Operational Implications
* Sales and Marketing
* Implications

To understand Rapid SaaS Development, you must first understand SaaS, Agile, and Rapid Application Development in general.

Rapid application development
Rapid application development is a software development methodology, which involves iterative development and the construction of prototypes. It is a merger of various structured techniques, especially the data driven Information Engineering with prototyping techniques to accelerate software systems development.

RAD calls for the interactive use of structured techniques and prototyping to define user's requirements and design the final system. Using structured techniques the developer first builds preliminary data models and business process models of the business requirements. Prototyping then helps the analyst and users to verify those requirements and to formally refine the data and process models. RAD approaches may entail compromises in functionality and performance in exchange for enabling faster development and facilitating application maintenance.

Agile software development
Agile software development refers to a group of software development methodologies based on iterative development, where requirements and solutions evolve through collaboration between self-organizing cross-functional teams. The term was coined in the year 2001 when the Agile Manifesto was formulated.

Agile methods generally promote a disciplined project management process that encourages frequent inspection and adaptation, a leadership philosophy that encourages teamwork, self-organization and accountability, a set of engineering best practices that allow for rapid delivery of high-quality software, and a business approach that aligns development with customer needs and company goals. Conceptual foundations of this framework are found in modern approaches to operations management and analysis, such as lean manufacturing, soft systems methodology, speech act theory (network of conversations approach), and Six Sigma. This is an example of an Agile-based development practice.

Software-as-a-Service (SaaS)
Software-as-a-Service (SaaS) is a model of software deployment whereby a provider licenses an application to customers for use as a service on demand. SaaS software vendors may host the application on their own web servers or download the application to the consumer device, disabling it after use or after the on-demand contract expires. The on-demand function may be handled internally to share licenses within a firm or by a third-party application service provider (ASP) sharing licenses between firms.

A Winning Combination
So, Rapid SaaS Development involves combining rapid application development with Agile project management for the development of SaaS applications. Most will tell you that if you are planning on building SaaS applications, you should certainly use Agile.

This blog posting by Rick Chapman of Softletter and SaaS University really gets you thinking about automation and the role of the Software Product Manager for SaaS companies.

In Chapman's 2009 Softletter SaaS Report, 47% of SaaS vendors reported that they had built feature management and request functionality directly into their products. And apparently the number is rising rapidly. Likewise, "SaaS companies are also implementing voting, polling, communities, peer to peer communications and more directly into the application environment." according to Chapman.

So it seems that rather than being simply keepers of the Tick List, product managers can leverage feature management tools to collect more ideas for enhancements, and spend more time validating the business value of each idea.

For new SaaS product development engagements, we tend to follow the 80/20 rule. We believe that 20% of the functionality delivers 80% of the value for any given software product. Thus when beginning a new product development, we urge our clients to focus on the 20% they can take to the market as a beta.

There are 3 major facets software companies must consider when transitioning from traditional on-premise software to SaaS:

*Business Model
*Application Architecture
*Operational Structure

When focusing on the SaaS Application Architecture, there are three key differentiators that separate a well-designed application from a poorly designed one.

A well-designed SaaS application is scalable, multi-tenant-efficient, and configurable.

Scaling the application means maximizing concurrency, and using application resources more efficiently-for example, optimizing locking duration, statelessness, sharing pooled resources such as threads and network connections, caching reference data, and partitioning large databases.

Multi-tenancy may be the most significant paradigm shift that an architect accustomed to designing isolated, single-tenant applications has to make.

Multi-tenant deployment is affected by complex considerations such as the design of the application's architecture, database schema, network connectivity, available bandwidth, and back office services (such as email, proxy, security). Fault tolerance and very high performance accompany multi-tenancy as critical for SaaS applications.

To assist software companies make a smooth and rapid transition to SaaS, its important to look at three major services.

The first component needed is a business consulting assignment to help ISVs to examine the SaaS business model for their own market and products. The engagement should cover business planning, market analysis, application evaluation and includes a SaaS business case and a working prototype. The latter can be used to acquire working capital for development phases, or can be presented to potential clients for buy-in and feedback.

The second component should be a SaaS Technical Assessment, that provides technical recommendations related to the issues that will affect the performance, scalability, manageability and security of the application, such as application architecture, tenancy and provisioning model options, integration requirements, database design, infrastructure architecture, development platform, and usability.

The third component should be SaaS Application Development services using resources experienced in building SaaS applications. The development team should be experienced with Platform-as-a-Service (PaaS) rapid development tools as well as custom development of SaaS applications.

We've given a couple of webinars recently with our partners Apprenda (archived copy here) and OpSource focused on the key issues ISVs need to consider when developing a SaaS product. One of the areas we covered that received a lot of interest was "Platform as a Service" - PaaS and what it can bring to a SaaS product development project.

Let me start out by saying that in the fog of high tech marketing hype - a great number of products are described as "platforms" for SaaS development. I'm not going to try to parse which specific products are or are not "really" platforms - it is too easy to get tied up in semantics and still not reach useful conclusions. In this article, I'm going to break down some of the services that are often called platforms and put them in a SaaS context.

First - let's define what functions you must perform - somehow - to effectively provide a software application as a service across the Internet:

* Pricing - A pricing engine or methodology must provide accurate, consistent pricing. In order to be really useful the engine or service should be flexible and allow for changes in the pricing system to accommodate new services or promotions.

* Billing & Payment Processing - Because SaaS is generally based on a recurring payment for services, a system or engine needs to be provided to bill clients and process payments. If there are elements of the service that are usage or transaction based, a part of the application needs to be dedicated to measuring and recording those factors.

* Tenant & Subscription Management - Each client account and the services they subscribe to along with their account status needs to be managed and linked to billing and payment processing.

* Service Provisioning - As each new tenant is added to the service, their "instance" needs to be provisioned. How this is accomplished varies a great deal and depends on the "maturity" of the service offering.

* Usage & Performance Monitoring - This is a very broad category of functionality that spans everything from monitoring individual user activities to the infrastructure that underpins the service. It should also include the accumulation of the raw data that will allow metrics to be derived for operations management.

* Subscriber Management & Self-Service - Each tenant should have ways of modifying their subscription, adding users, changing user roles and monitoring their current usage.

We sometimes refer to these functions as "SaaS Plumbing" because they are operationally necessary regardless of the business rules and expertise that defines your specific product. Of course, the best case is for all of this to be handled within the application "stack" in more or less of an automated fashion. In addition, a true multitenant architecture addresses these issues in the context of a single application instance. To develop a SaaS application that includes these functions in a multenant architecture typically takes from 20 to 50% of the whole development effort. If you do not want to incur this overhead in your application, you have two choices - do some or all of the work manually or use some type of service that provides the functionality for you.

With this background, the basis for the various services and platforms that are available to SaaS developers begins to fall into various levels of functionality and value. To help separate the "wheat from the chaff" a little further - let's consider what the true, multitenant SaaS "stack" looks like:

The layers of the stack include:

* Infrastructure - Network, Servers, Storage, Load Balancing, etc.

* Technology Stack - OS (Windows, Linux, etc), Database, Application Environment (.NET, Ruby, PHP, etc) and associated services.

* SaaS Functionality - The "SaaS Plumbing" and services outlined above.

* Application Logic - The core business rules and functionality of the service to tenants.

With this common understanding of the SaaS stack, we can start to break down platforms and services for SaaS according to the layer(s) of the stack they address.

Most "platforms" are common to all application development. These address infrastructure and technology stack layers in one way or another. A common example would be something like Rackspace Managed Hosting. A platform in this category can include anything from a single dedicated server to a virtualized cluster, along with the OS, environment, database, reporting and monitoring that application installations typically require. Depending on the services the provider offers and you select, these platforms can greatly reduce the overhead in infrastructure and server deployment. They can improve reliability and provide development environments that lower development effort and improve application reliability. But - they do not specifically address the functionality that is required to operate a SaaS application.

This is where we start to run into problems...

The marketing for most products described as "PaaS" for SaaS today includes some combination of the infrastructure and technology levels of the stack and quite often impacts the way the application logic is expressed. They rarely address multitenant architecture or any of the SaaS functionality that impacts the operational needs of your service. Depending on how they are configured, they can often represent a certain amount of risk through "lock-in" to their service. A recent example of this is the Coghead system which provided the infrastructure and deployment services but in the process provided a development environment that was unique to itself and hard to break away from when the service began to close. These factors don't lessen the advantages of these platforms, but they do shed some light on their utility for SaaS development specifically. They can be invaluable in the SaaS stack but it is critical to assess up front how they will impact service costs, risk and what they leave on the table that still needs to be developed.

At this time, finding a more complete stack is still a bit of a challenge. Apprenda's SaaSGrid, Force.Com and Zoho Creator are some of the platforms that in one way or another directly address SaaS. Each has its own pluses and minuses in terms of the functionality they provide and the impact they have on application development. Beyond those, you can use services that address SaaS functionality on top of one of the more general application platforms. This brings on another level of risk - you are now piling together the general platform and perhaps services from several other sources - but this is not uncommon in eCommerce or business-to-business applications so you're not really breaking new ground if you have experience developing applications for the Internet. Each service addresses a specific range of functionality and again - you need to go back to the list of SaaS functionality to see what you are getting in return for the cost and risk. A good place to start is the SaaS Showplace.

In addition, there are hosting providers - like OpSource - that provide a mix of services for SaaS applications as a part of or on top of their infrastructure. This type of offering lowers the risk because they are centrally controlled and generally provided across the data center instead of across the Internet.

In truth however, there is no PaaS that will addresses all the needs of a specific SaaS operation but - we do find repeatedly that using services and platforms allows the product team to focus on the value features of an application, reduces the time-to-market and costs of development. Assessing what is needed and what is of most value is necessary in the front end of every project and quite often the hardest thing to explain to clients until they get into the "plumbing" themselves. Making the decisions necessary takes planning and consideration, but re-architecting a service after it is on the market is - as anyone who has tried it can tell you - not something you "want" to do without serious pain to prod you.