How SaaS Fits into the Multicloud World

SaaS applications rarely operate completely independently. Companies often have an IT landscape that looks something like this: SaaS for CRM, a second SaaS for human resources, in-house analytics hardware behind a firewall, and AI for testing. Much of this information is fed into their enterprise resource planning (ERP) system that may be housed in their data center. Providing processes that allow information to securely flow among these systems is critical. The figure illustrates this hybrid SaaS environment.

The environment described here truly is a hybrid cloud, and it is probably a multicloud environment as well. It’s a hybrid cloud because the SaaS applications are in a public cloud while the analytics are on-premises. It may also be a multicloud because the SaaS applications may be in different public clouds. These applications ultimately need to work together to provide full business value. Of course, a hybrid or multicloud environment can be simpler or more complex than the one illustrated in the figure.

Where do SaaS applications run? A SaaS vendor might run its software in the physical data centers it operates. Salesforce.com did this originally out of necessity because it was an early innovator without other options. Other vendors — for example, SugarCRM — run their SaaS offerings in public clouds, such as Amazon AWS or Google Cloud Platform. A SaaS running in a vendor’s data center isn’t necessarily more stable, but great software on an unreliable third-party platform is useless. So, it’s important to understand service level agreements (SLAs).

The ability of a SaaS application to run in different environments is important for many reasons, just as it is for almost any other application. Consider these examples:

• Physical location may make a difference. Some SaaS applications need to be close to their users. For example, a high-speed video streaming server will provide a better user experience if the data does not have to travel long distances. In addition, some businesses have governance rules that require that their data be located in the country where the company is based.
• Software location may make a difference. When SaaS applications interact with other applications, performance will benefit if they’re both in the same cloud. This may not be necessary for simple interactions, but as data quantity and communication rates increase, it becomes more important. This is one of the reasons you may find the same SaaS application in different public clouds.
• Flexibility may make a difference. Not all clouds are equal, and all clouds are constantly making changes to their offerings and prices. SaaS vendors should stay aware of each cloud environment and be ready to move their applications to the cloud (or clouds) that provide the best platform for their applications.

SaaS applications live in diverse environments, integrated with many services and other applications. Although this setup increases complexity, it also provides new opportunities.

So, when a division of your company wants access to all of an application’s data so that it can run analytics, it is no longer reasonable to say, “Sorry, that’s in the SaaS application.” Instead, you can now replicate the data onto your private cloud where the analytics team can make a copy of the golden master (a single version of the truth for the data — the reference model) to run its sophisticated number crunching, and other groups, such as development, can make a copy of the data and use it for testing in a public cloud.

Using SaaS as a cloud computing platform

In order to create a more feature-rich application, some SaaS vendors have turned their application into a cloud computing platform upon which partners and Independent Software Vendors (ISVs) can build applications that extend the SaaS platform. This model represents an ecosystem that extends the functionality and value of the SaaS application. Typically, these ecosystems are domain-specific, for example addressing healthcare, CRM, or other business focuses.

This is how it works: A SaaS vendor with thousands of paying customers opens its APIs to ISVs. These ISVs can then build applications on top of the SaaS vendor’s infrastructure. Therefore, they don’t need to write and deploy an entire application, but can focus on their specific extension of the SaaS platform. By building general domain functionality into the platform, the SaaS vendor attracts other vendors within that domain. Further, the SaaS vendor that created the platform typically takes care of messaging middleware, business process services, and other complex programming.

Note: A SaaS platform is fundamentally a PaaS provider to the partners and ISVs who build applications in the SaaS ecosystem. When an application is built on the PaaS platform, there is no need to specify an operating system as would be required if the platform offered an IaaS service. By offering only the services that are consistent with the domain addressed by the SaaS. the SaaS vendor exercises control over the applications built on the platform, ensuring that they address the SaaS’s domain.

Perhaps the most significant advantage to working in the ecosystem is that the SaaS vendor already has thousands of happy and paying customers. After a partner creates an application, it can market its software through the SaaS vendor’s portal in addition to using its own traditional sales force. This has become a standard model used by SaaS vendors to build their brand and power in the market.

Who builds applications on SaaS platforms

In this section, we take a closer look at the types of application developers that are suited to building their domain-specific applications on a SaaS platform. Partners and ISVs can be broken into two general categories: smaller startups and larger, established companies. It might be clear why a small company with limited resources might be motivated to build on top of, for example, the Salesforce.com platform, but if you’re a large player with your own customer base, why would you be part of another company’s ecosystem?

Established companies may want to join another company’s online ecosystem for many reasons. Software vendors with successful on-premises applications are receiving pressure to offer a cloud version of their software. One challenge that these larger ISVs face is that in order to have a successful, enterprise-class application, they must create and establish their cloud presence. Joining an existing ecosystem that has already established their business and attracted customers shortcuts the path to customer awareness.

Both large and small companies benefit by using the PaaS environment of the SaaS platform, which can dramatically decrease the amount of software that must be created to form a mature application, thereby increasing time-to-market.

Consider Veeva Systems, a software vendor that has developed a cloud-based CRM solution for the pharmaceutical, animal health, and biotechnology industries. Veeva built its software in the Salesforce.com ecosystem. Without Salesforce.com, Veeva would have had to create a completely new platform from scratch — a monumental and expensive endeavor for a small company. Salesforce.com can’t meet the unique needs of every industry, so where Salesforce.com falls short, partners like Veeva step in.

For example, pharmaceutical companies must comply with specific regulations. Veeva has built-in functionality to track and report the required information. Because Veeva controls software and process updates, when reporting requirements change, it updates the application so that all its users have access to the most up-to-date offering and are in compliance with government regulations and industry practices.

One might think that building a SaaS application in another business’s ecosystem would devalue the application. However, the opposite is often more likely. You have no doubt noticed how food vendors at a mall are all located in the same area. Sometimes called the food court model, related businesses can do very well when co-located, not least because the customers attracted to the ecosystem are all highly qualified to do business with the vendors there.

Developing on a SaaS vendor’s platform

Clearly, there are great benefits for ISVs that build applications in an established ecosystem, but these independent development companies may be at the mercy of the SaaS vendor. The SaaS vendor develops and maintains the platform, and the ISVs who have built applications on the platform are then dependent on it operating predictably. If the SaaS vendor does an update, the platform may possibly change its behavior in a way that destabilizes the ISVs’ applications.

Of course, stability and consistency over time is important for any platform, from cloud infrastructures to operating systems. But SaaS platforms are relatively new, and SaaS businesses may not have as much experience in maintaining them. To protect themselves, independent vendors should have the opportunity to thoroughly test their application on a newly modified platform before upgrades are released to end users. ISVs should research a SaaS vendor before developing on its platform to verify it provides the stability required to safeguard applications.

However, in practice, the relationship between SaaS platform vendors and their ISV partners is symbiotic — each needs the other for success and growth. A SaaS platform should document its APIs and state how long they will be supported. The success of applications on a SaaS platform will benefit the SaaS vendor, just as failures will be attributed to the platform. Applications built on the SaaS platform will be branded with the creating company’s name, and they will, therefore, also be credited with the application’s success or criticized for failure.

Examples of SaaS platforms

Like so many things cloud, SaaS applications have reached a certain degree of maturity — marked by users taking new SaaS applications for granted rather than marveling over every new SaaS application. In the following sections, we explore a selection of the major types of SaaS applications.

SaaS business applications

From accounting software to customer relationship management, supply chain management, financial management, and human resources, there are SaaS applications for all the standard business practices. Not long ago, many of these functions were custom-created and run in on-premises data centers. Now, they’re in the cloud and generalized to make them suitable for the vast majority of businesses.

These products tend to have several characteristics in common: They’re designed with business processes built in that customers can modify; they have published APIs so that third-party vendors and businesses can add functionality. These applications have moved in great numbers to the cloud because customers found the on-premises systems too hard to manage, and users need access to the application while on the go.

SaaS collaborative applications

SaaS is very popular for collaborative applications. This area is dominated by software that focuses on bringing people together — and most people are already in the cloud — to work together on shared activities. For example, web conferencing, document collaboration, project planning, instant messaging, and email and all collaborative applications. In a sense, it was inevitable that these platforms would move to the cloud. These tasks exist throughout the organization and need to be easily accessed from many locations.

SaaS development services

With more and more companies building software for the cloud, it’s not surprising that many companies are building services that make it easier to build applications. Services means online software that is intended to be a part of an application, not an application itself.

Examples of development services include

• Monitoring as a service: SaaS applications usually work well, but even the best can run into problems. Issues can come from bugs in the SaaS, reactions to unanticipated situations, or problems outside the SaaS. In each of these cases, the SaaS vendor needs to quickly understand what is going on and remedy it. They’ll be lucky if they can fix the problem before customers start calling the support line. And if customers do call the support line, support personnel need to understand what the problem is so that they can help the customer work around the problem. Monitoring software examines many sources of information about the SaaS application and its operational context and delivers it to support, development, and other business units.
• Compliance as a service: Compliance responsibilities are time-consuming and complicated tasks that large companies must perform. Because compliance is a well-defined activity, yet very involved with many special cases, many companies have implemented compliance solutions as a service so the SaaS company doesn’t have to.
• Security as a service: Almost without exception, vendors providing antivirus software are offering their products as a service. However, security extends much further than looking for viruses in communications. Increasingly, security is an activity that is part and parcel of software development and must be designed into software as it is being designed and built.
• Database (and other components) as a service: Every application works with data and needs to store it, and databases (in this context, DBaaS, or Database as a Service) are the standard tool for storage and management of data. Every cloud environment offers many types and vendors of databases. Typically, it takes only a short time, perhaps minutes, to provision and launch a database and start using it. Other components used to build SaaS applications are also available for use in the cloud, including identity management, credit card processing, analytics, big data storage and analysis, and so on.