Can SaaS even have a methodology?

By Arthur Lawida, Managing Partner
SaaS Accelerator

A couple of weeks ago, I was reading several blogs about SaaS where they claimed that the move to SaaS was very similar to the move to client server technology in the 90’s. The claim was that you could not have a SaaS methodology. They said that having a SaaS methodology was comparable to having a “client server” or “mainframe” development methodology and just didn’t make sense without being tied to a particular application.

I think that misses a major point of cloud computing. SaaS means that “software” is fundamentally replaced by “service”. SaaS is not a software deployment model; it is a fundamental shift in the way we think about providing business solutions.

One of the key differentiators between mainframe and client server technologies, and today’s cloud technologies, is that control of the application has become increasingly difficult. In a cloud or SaaS model, an application is no longer highly centralized (mainframe) or tiered (client server). It has the capability to be fully distributed. Depending upon the requirements and the capabilities of the software vendor, these application parts can be customized, semi customized or not customized and each one can be premise based, on-demand or fully SaaS.

What this means is that in order for an enterprise to deploy a SaaS based application today that maximizes the potential of the cloud, even more rigorous planning must be applied up front. Some of this planning tracks with traditional development methodologies but some of it is new. Here are some thoughts on the “new” areas that we have designed into our methodology:

1. Security: When dealing with sensitive data, how do you insure that the cloud is secure? In ecommerce applications and medical applications there are security standards. If one of the software providers has the appropriate certifications, is that enough?

2. Requirements Analysis: Usually business requirements are prioritized on the basis of their value to the business. In a cloud model, another aspect must be analyzed. Customizing SaaS applications is not straightforward. Each requirement must be assessed in terms of its ability to be customized by the SaaS vendor providing that service.

3. Application partitioning: What parts go where in the cloud? What functions are business critical? Disaster planning takes on a whole new aspect when you have to worry about not just the technical infrastructure but the financial health of each participant of the SaaS application. If they go out of business, what are your recovery options?

4. Indirection layers: To support the above requirement, what data and application indirection layers need to be created by the enterprise so that a particular software service of the cloud can be easily replaced by another service if the original service becomes unavailable?

5. Quality Assurance: QA, especially integration and system testing, must take on the role of becoming knowledgeable and proficient in testing disparate software services.

6. Operations: How does the enterprise provide things like uptime guarantees, training, support and user documentation for an application spread among several service providers?

To summarize, I think there are a core set of issues that make a SaaS deployment methodology useful regardless of the application. Our methodology works to mitigate risk and increase the chances that the enterprise will be happy with the result.

SaaS is not just another software deployment architecture. It is much more like the move from structure programming to object oriented programming except at a meta-level. More to come on that point because I have found a lot of thinking has gone on around service oriented architectures at the single service level but I cannot find much that views entire applications as a services linked together to create a business solution.

SaaS Customizations: The 500 pound Needle in the Haystack

By David Ebel, Principal Consultant
SaaS Accelerator

When embarking on Software as a Service implementation projects, few things are more underestimated than the solution customizations which will be required to make the final product suit the enterprise operation. In my experience the scoping of solution customizations is the most critical aspect of a SaaS project.

Solution customizations are the project aspects most likely to cause delays in launch and budget-exceeding costs. Moreover, many customizations are required for launch and can hold up the entire effort if they are not properly identified and scoped early on. Your best bet is to rely on your internal staff or a hired expert to assist in determining your SaaS customization needs prior to beginning the implementation of your project.

What commonly goes wrong?

Fundamentally, SaaS providers have made a bet that their solution will work for a broad spectrum of a specific market and that customizations will be brief and superficial. Unfortunately as the role of these applications becomes more core to enterprise organizations, the critical customizations required are much more than simple bullet points on a project plan template.

In many cases clients are trusting that the solution provider will come to understand their business and have the time and expertise to make the "out of the box" solution fit their business needs. This expectation can be costly to the client, since solution customizations are not commonly core to a SaaS company's business model.

To resolve this issue it is important that the client project leads:

• Thoroughly review the “out of the box” functionality the SaaS solution contains
• Identify gaps that will need to be met with vendor or client hosted customizations
• Thoroughly describe the details of these requirements prior to project start

Once this is completed, the vendor can be held accountable to meeting the requirements outlined by the client, according to a mutually agreed upon time frame.

Taking the responsibility of determining solution gaps away from the vendor and giving it to an experienced independent client advocate is an excellent way to improve the project scoping process. Simply put, it stops the dependence on the SaaS vendor to provide critical project requirements in an area where they are reasonably not equipped to be the expert. After all, no one understands your business like you do.

The 500 pound needle in the haystack is not impossible to find or manage properly. It takes focus, experience, and decisive action to ensure that a SaaS project is scoped thoroughly and customizations are accurately identified early on. Once this often overlooked concern is addressed, the project can be brilliantly handled so that everyone will be celebrating the launch right on time and within budget.

Enterprise SaaS Solutions: A different animal

By Arthur Lawida, Managing Partner
SaaS Accelerator

Enterprise SaaS Solutions are not the same as traditional SaaS applications. Initially, companies like salesforce.com delivered lightweight, single use applications in an on-demand model. These applications were barely customizable and extremely difficult to integrate with other enterprise level applications or within the enterprise information architecture.

SaaS applications have been moving upstream for the past couple of years into departmental and even enterprise wide solutions that are being customized to meet specific business requirements and fit within the enterprise architecture.

The traditional benefits of SaaS include:

1. Easier, faster and (hopefully) cheaper deployment.
   
2. More efficient and less costly management and operation.
   
3. Leveraging innovation investment across multiple enterprises.
   

The major downside is that since true SaaS Solutions exist in a multi-tenant (shared) environment, customizations are more difficult and the speed that those customizations can be delivered are often lengthened. Even if it is informal, negotiations must go on about every customization requested to see if it would be valuable to the other tenants and against all of the other customizations being delivered on the platform.

The tension between these competing desires (customization vs. SaaS benefits) is where every enterprise and SaaS vendor have their biggest deployment "discussions".

A specific methodology has to be employed that matches the enterprise requirements against the strengths and weaknesses of the SaaS application to find the optimal solution that leverages the benefits of the SaaS application and does not degrade the usefulness of the solution to the enterprise. After all, if the enterprise is talking to a SaaS vendor at all, they have probably already chosen it over a custom solution and know there will be tradeoffs. The key is getting the SaaS solution provide to understand the client's business and the client to understand the SaaS solution enough to reach the right compromises before deployment requirements are finalized.