In-Depth

Q&A: The True Meaning of SaaS and Shared Services

How the terms software-as-a-service and shared services are being used, what they really mean, and where the technologies are headed.

Terms such as software-as-a-service (SaaS) and shared services are frequently tossed about in BI and data warehousing discussions. In this interview, we talk with Tim Walters of Collaborative Consulting, a technology consulting firm that delivers solutions in data services, technology services, project management, and operational services worldwide, about how those concepts are being used today -- and how they may evolve in the future.

Walters is the author of a white paper on the benefits and challenges of software-as-a-service in building a data warehouse and BI shared service, and spoke on the topic at the SAS Global Forum Annual Conference in Washington, DC in March.

BI This Week: When we talk about shared services, software-as-a-service, and BI, where are we on the implementation curve?

Tim Walters: For BI as SaaS, we are very early on the implementation curve, and even less far along with BI as shared services.

Back in 2005, I started on the path to implement what was then a vision and strategy for a large data warehouse and BI shared service. At that time, there were no examples in the public or private sectors that could serve as models in developing the myriad deliverables necessary in the project initiation phase. Those deliverables included a business case, logical architecture, cost recovery model, detailed service catalog, and customer pipeline. Figuring out all of those components wasn’t a simple undertaking -- it turned out to be a collaborative effort between vendors, partners, and internal experts.

Fast forward to today, when most BI vendors are in the early phases of developing offerings that are mainly based on the application service provider (ASP) model or a multi-instance architecture. In other words, they are focused on many-to-many deployments that physically separate each customer’s data warehouse from other customers, requiring entirely separate software installs and separate physical application servers. (As exceptions, there are some vendors that offer certain BI capabilities, such as reporting, in a true SaaS environment.)

Our goal was to implement shared services in a multi-tenancy architecture, a one-to-many installation and configuration of the application software. That reduces the software licensing fees, ongoing maintenance costs, and staffing costs required for the care and feeding of the platform. Our data warehousing shared service model was that of a utility, similar to telephone, electricity, or gas utilities.

Can you differentiate between “shared services” and “SaaS”? How are those two terms generally being used?

SaaS refers to applications that are consumed over the Internet. They don’t require installation on a customer’s desktop, and they don’t require server infrastructure. It’s a model that significantly reduces the customer’s burden in terms of maintenance and upgrades, installation, configuration, and disaster recovery.

Shared services is a term that we use at Collaborative Consulting to describe the provisioning of a service by one part of an organization where that service had previously been found in more than one part of the organization. This doesn’t mean simply consolidating a function, it goes farther -- you are running the shared service as a business and delivering services to customers at a cost, quality, and timeliness that is competitive with alternatives.

SaaS and shared services are complimentary; in the case of data warehousing and BI shared services, they can maximize efficiencies. Other value multipliers that are imperative, incidentally, are service governance and service-level management.

What are some concerns that arise when you talk with BI- and data–warehouse-savvy customers about the concept of shared services in BI? You’ve said that making the case for SaaS isn’t just a technical issue -- it’s a business one. What are some of the business issues, and how do you address them?

SaaS and shared services for BI are an easy sell to the IT side because the tangible benefits to IT are clear from a cost-savings perspective. Examples include centralized management of enterprise software licensing, specialization of service support personnel that are shared across the customer base, reduction of IT risks (obsolescence, skills, and change), and optimization of the infrastructure.

On the business side, decision-support capabilities are very strategic and represent an organization’s competitive advantage, which is why most organizations insist on keeping these assets close. Organizations are used to being able to log on to the physical servers with a host account -- in a shared service model, they don’t have this access. We mitigate this concern by explaining the security and partitioning of information from each other tenant of the service.

Another concern is rooted in human nature and information politics, especially within large organizations that are focusing on integrating data across silos. Some managers avoid sharing data for fear of losing power and control. Frankly, these concerns are the hardest to overcome. I’ve heard it called the “data mining” syndrome (I don’t want to share my data!). The only way to break that barrier is to have top-level executive support and authority to clear away those barriers for the greater good of the enterprise. In fact, shared services and enterprise data integration efforts aren’t possible without this top-level blocking and tackling.

The bottom line here is that you must do your homework and build an excellent business case that demonstrates the real, tangible value that a shared data warehousing and BI service can deliver to the organization while managing the risks. A shared service has a large scope and a diverse population of stakeholders, requiring a business case that shows tangible and achievable benefits quickly and over the long term, with something for everybody.

Let’s talk about the security of the data. What are some best practices for addressing that when choosing a partner for shared services/SaaS?

Data access and security is one of the top concerns to all potential customers of a shared BI service. How do you know that your data is protected and secure? In addition, some customers may have regulatory compliance rules for data that are difficult to comply with in a shared service.

Examples of good practice include:

  • Use security requirements as part of the tool selection process.
  • Gather security requirements from the business, as part of the requirements-gathering process. Understanding the priorities and critical issues of the business units is a crucial first step and one that shouldn’t be overlooked.
  • Create a proof of concept or prototype with security needs clearly proven.

Regarding return on investment, what sort of cost recovery models are available for shared services?

Cost recovery models are vital to ensure that your shared service can secure the needed funding to remain viable and provide value to your customers over time. As I mentioned earlier, we did not have a reference-able example of a cost recovery model for a BI and data warehousing service, so we experimented with different models. We settled on one based on a monthly subscription fee.

Cost recovery models can become fairly complex, so you must be careful to build one that achieves your goals. It should be simple and transparent enough to be easily understood by your customers. You don’t want to penalize customers for heavy use of the service since data warehouses are meant to be exploited to maximize their value. The recovery model should be neutral to usage and be based more on the resource capacity required to meet each customer’s unique service level requirements.

Several shared services are based on subscription fees; others are charged on a per-seat basis. Other models are federated, pay-as-you-go, or hybrids. Regardless, your model should be designed to recover all costs and either break even (in the public sector) or generate profits or surpluses, or both, that can either be refunded to customers or invested back into the service to stay competitive with alternatives.

What is Collaborative Consulting doing right now in the shared services arena?

We’re seeing tremendous interest in this topic. With an increased focus on efficiency and cost containment, our clients have sought us out to provide a continuum of consulting services from advice and strategic direction regarding shared services, through to implementation and operation of shared service environments.

For example, we have helped several of our service-provider clients envision and create solution platforms that will allow them to scale BI environments in a multi-tenant model providing focused analytics that compliment their current service model. In other cases, we have helped our internal IT support clients provide shared service solutions for their internal customers in the form of data integration frameworks, BI frameworks, and in at least one case, an entire service group dedicated to reporting and analytics provisioning across the enterprise.

The internal shared service model works well for functions that span multiple business areas, while having a common technology baseline and similar set of overarching requirements. While a lot of the work we have done has been inside an organization, we’re now seeing customers with a keen interest in SaaS models outside their four walls. Our role in the BI market evolution has been primarily strategic, helping companies decide if SaaS makes sense for their organization and their particular BI environment. As the marketplace grows in acceptance, however, the challenge will move from direction-setting to integration.

Must Read Articles