On Demand and SaaS

by Thomas Moewe
Managing Consultant

The concept of On Demand is often found surrounding the topic of SaaS. Recently I've found myself in several discussions regarding the two concepts, how they are similar and whether it is correct that they be tightly coupled.

I spent much of the last decade with IBM, who is responsible for much of today's vision behind the On Demand Enterprise. Similarly, IBM put much of the marketing muscle behind the concept of eBusiness in the 1990's. I've found that looking at the similarities between On Demand and eBusiness is a good way to understand how SaaS relates to On Demand.

SaaS is to On Demand as eCommerce was to eBusiness. That is, SaaS in itself does not deliver the On Demand Enterprise, just as eCommerce in itself did not deliver the vision behind eBusiness.

SaaS is an enabler of the On Demand Enterprise and a key step in the direction of realizing its' promise. As an organization embraces the concept of the On Demand Enterprise by investing in SaaS solutions, it is critical to take a holistic view of the enterprise to understand where SaaS fits and avoid building what we call SaaS stovepipes.

SaaS Accelerator's strategic consulting practice takes our clients through a 6-10 week process to look holistically at the enterprise from a business and technology perspective to create a multi-phased roadmap for realizing the On Demand Enterprise. By understanding the desired capabilities of the business and the underlying architecture to deliver the capabilities, the roadmap helps client to make better informed investments and avoid short-term technology decisions.

Are services part of SaaS?

by Arthur Lawida

Managing Partner

Once you get past a simple SaaS application and into a broader SaaS Solution, it quickly becomes clear that software as a service is not enough. Often, people decide on SaaS Solutions because they do not have (or want) the in-house expertise to run all or part of their technology deployment. Just as often, they want to outsource all or part of their business operations as well.

This makes a great case for service companies like SaaS Accelerator getting involved to deliver needed services within the SaaS solutions they deliver.

As an example, one of the focus areas for our company is eCommerce. Ecommerce solutions delivered on a SaaS platform like Vcommerce often require several other applications to fit the requirements of an enterprise solution. Search, analytics and customer relationship management are all often required to be integrated into the platform to meet the client's business requirements.

From a services perspective there are several areas of engagement that should be considered to assist a client with a complete solution. Customer service, online marketing, product merchandising, merchant accounts, and supplier selection are all areas that we have seen client's need assistance.

The interesting question is where does the responsibility (and opportunity) for finding and recommending these services lie? Certainly, part of the responsibility lies with the SaaS vendor, especially if they are either early in their development efforts or fielding a Platform as a Service. In the end the business responsibility is with the client but we believe there is a significant opportunity for services companies in this space. Unlike the SaaS vendor, service companies have a core competency in the delivery of services and have the capability and opportunity to develop and deliver true services around each SaaS solution mash-up. If a services company focuses on delivering all of the services around a particular SaaS solution, the upside becomes a deep and integrated knowledge of that solution area leading to more value for the client.

Teamed with the client and the SaaS vendor, these services start to make a more compelling case enterprises to consider an enterprise SaaS solution because they can solve both their technology and business challenges in one package.

SaaS Knowledge Innovation

by Arthur Lawida
Managing Partner

At first glance, companies usually consider SaaS solutions in order to reduce implementation and operational costs. The TCO of a SaaS solution should be less because the core operational costs are spread across all of the tenants.

While this alone is a very good reason to consider a SaaS solution, I think the best reason for a company to consider SaaS has more to do with leveraging the shared innovation that becomes inherent in the solution over time.

At one level, this innovation is in the technology. When tenants ask for enhancements to the core technology, all can benefit and share the costs. When a client asks for a core enhancement, the SaaS vendor must analyze the usefulness to the other tenants. Depending upon the result of this analysis, the cost to the client who requests the customization can range from the entire cost, if it is not likely to be a shared innovation, to completely free if the SaaS vendor feels the innovation will significantly enhance their core offering. In all cases, this ends up in a negotiation based upon functionality delivered, time to delivery and cost.

What is often overlooked by the market is the deep knowledge and wisdom that becomes collected at the SasS vendor across both vertical and horizontal markets served by their solution. This experience can be an extremely valuable asset to a new tenant, especially if they are entering a new business area or sales channel.

Whether it is an eCommerce solution or an HR solution, the SaaS vendor is likely to have seen practices develop over time that it can share with the new client in a way that does not violate the confidentiality of the other tenants. This kind of knowledge, gained from actual operating experience, means each new client doesn’t have to make the same mistakes everyone else made and over time will become a vital differentiator between SaaS vendors and premise based solutions. The key is that unlike traditional software companies, SaaS vendors must operate their client’s businesses and this provides a significantly faster feedback mechanism to drive further innovation into the shared platform.

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.