Multi-Tenancy, Platforms, and ISVs

Eric Farrar

The thoughts and opinions expressed in this blog post are my own, and do not necessarily represent those of Sybase or SAP.

This past week an article written by my colleague, Eric Lai (Twitter), entitled Multitenancy & Cloud Computing Platforms: Four Big Problems, caused quite a bit of controversy. An example of this is the formal rebuttal by independent consultant Frank Scavo (Twitter) in his blog post, Mischaracterization of Multitenancy in an SAP-sponsored Blog Post.

As Eric noted in his article, this post was motivated by a discussion that he and I had about multi-tenancy around Sybase’s forthcoming SQL Anywhere OnDemand cloud database. In this post I will respond to Frank’s comments, attempting to frame the discussion in the context that the article was intended. I think we will find it is all a matter of hats. To that end, I invite you to put on my hat for a moment.


My Hat

I am a product manager on the SQL Anywhere team. For those who are new to SQL Anywhere, it is an embedded relational database that has been in development at Sybase for over 20 years. Although you may never have heard of it, there is a good chance you have used it. This is because it is typically so deeply embedded in an ISV’s product that you do not know it is there. An example of an application that embeds SQL Anywhere is Intuit’s QuickBooks.

Over the last two years, we have started to see a shift in the ISV community. ISVs who previously used to deploy an application to their end users (and have it run on-premise) are feeling pressure to have a hosted version. This turns an ISVs core competency on its head. After all, ISVs have expertise in deploying software, and managing deployed software. While hosting removes those challenges, it puts the challenges of hosting in their place. This is an entirely new world for many ISVs.

To capture this shift (and other shifts within IT), many companies have launched full-stack, public platforms-as-a-service products. These are multi-tenant platforms where the resources are shared between hundreds of different applications running on the platform. The promise of the PaaS is that it will take care of the hosting, and it will scale your application automatically.

There is no such thing as a free lunch. The tradeoffs come in four places: flexibility, security, power (or functionality), and cost. Now that we are all wearing my hat (also known as the ISV-looking-for-a-platform-to-host-their-application hat), let’s take a look at the objections raised in Frank’s response.

It’s Inflexible

When choosing a platform, any platform, you have entered a garden. Some of these gardens have quaint white picket fences with lots of gates and a nice breeze. Others have tall, thick, brick walls.

On a PaaS, the ISV will be limited to the physical locations, certifications (HIPAA, PCI-DSS), hardware, technologies, and terms-of-service of the platform provider. This rigidity causes problems if the ISV has current (or future) requirements that can not be met by the platform provider.

So what does multi-tenancy have to do with this inflexibility? Whether speaking of a platform or an application, it is often the multi-tenancy aspect that limits the amount of flexibility that an application or platform can support. I am not saying that multi-tenancy is bad, just that it is usually inversely correlated with flexibility.

It’s Less Secure

The question of multi-tenancy for an ISV has two facets. There is the question of the multi-tenancy of the platform they are running on, and there is the question of their ability to create a multi-tenant application.

I am not aware of any published security breaches between separate applications running on a multi-tenant platform. Each application running on the platform will likely have its own database, and so the risk of data leakage is mitigated. I believe that the platform providers will have done a lot of work and testing to ensure that separate applications on their platforms are isolated.

But the platforms do not provide any help in isolating the data within an ISV’s own application. When an ISV deploys an application on-premise, each customer gets their own instance of the application (with their own instance of the database). When the ISV pulls all of those customers together to host the application, does it make sense to combine all of the customers’ databases together into a single database?

Most of the PaaS stack’s databases have been designed to scale with the absolute size of a single database. This metric of scaling suggests that it would be best to combine all of the customers’ data into a single database. This creates a potential risk because it is possible that the ISV could introduce a bug that accidently exposes one customer’s data to another. The most likely cause of this is a coding error. (eg. forgetting to filter the data to just that customer, a bug that causes confusion of the customer identifier, etc)

Cases like this have happened in the wild (emphasis mine):


  • Microsoft BPOS cloud service hit with data breach


“We recently became aware that, due to a configuration issue, Offline Address Book information for Business Productivity Online Suite (BPOS) Standard customers could be inadvertently downloaded by other customers of the service, in a very specific circumstance,” said Clint Patterson, director of BPOS Communications at Microsoft.



  • users were logged into someone else’s account


“Hulu said shortly after launching its Facebook Connect feature Friday that it noticed a small number of users were seeing someone else’s account information upon logging in to the site.”


“We’re still drilling down on the precise nature of the issue, but we know that it was a coding and configuration error on Hulu’s side, and not the result of hacking, or other third party actions”

(Official Blog)

Both of these are large companies who I expect have the resources to design and test their multi-tenant solutions, and yet both had (thankfully, limited) data breaches.

The concern of many smaller ISVs who are brand new to hosting is that they will not do it correctly. I would expect that data breaches of this nature are more common, but it is just that many smaller ISVs do not have the profile to have their breach featured in ComputerWorld or VentureBeat.

One solution for the ISV is to keep total isolation of the data between all of their tenants. One tenant, one database. The application layer may be multi-tenant, but the database is single-tenant. While some of the platforms will allow you to maintain multiple databases, it is not cost-effective, and they do not have any tools to help manage thousands of separate databases.

This is exactly the use-case for which SQL Anywhere OnDemand was designed: a multi-tenant application layer, backed by a single-tenant database layer.

I want to make it clear I am not suggesting a multi-tenant application is inherently insecure. (After all, we are enabling our ISVs to create multi-tenant applications!) Instead I am suggesting any developer should only include multi-tenancy up to the level they are confident that they can make secure. For many ISVs who do not have experience in multi-tenancy and hosting (and whose apps are already written as single-tenant applications), it may be prudent to keep the databases single-tenant.

It’s Less Powerful

As Frank points out, the platforms allow for huge improvement in productivity. I have no argument here. However here as well, there is no free lunch. The productivity gain is inversely correlated with power and functionality.

When I have to write a quick script, my language of choice is Python. I love Python. Our SQL Anywhere database is written in C/C++, with some performance critical routines written in assembly. Would it be a wise choice to rewrite SQL Anywhere in Python? No, it is not the right tool for the job.

Many of the ISVs using SQL Anywhere have very database-intensive applications. They move large amounts of their code into stored procedures in order to reach their performance goals. Moving the logic out of the database, and going through an abstraction layer (eg. Object-Relational Mappers) may not be an option for them.

This really comes down to the same conclusion as the flexibility argument. If the restrictions in functionality (which allow the boost in productivity) are acceptable to you, great. If they are not acceptable, that platform is not an option.

It May Be More Costly

As Frank asserts, this is speaking of the cost to the ISV, not the end customer. The reason for this is that many ISVs are smaller shops who do not have the bandwidth to fully re-architect their application to fit the constraints of a platform. They need their application hosted, and they needed it done yesterday.

Many of the ISVs that I have talked to plan to accomplish by doing it in stages. The first stage is to move the existing application and database up a hosting provider, and use remote desktoping technologies to remote the application’s GUI to the end-user

I can almost hear an audible groan of disdain from cloud purists:

“You can’t do that! The application must be totally re-architected in order to take advantage of the cloud.”

That is true, but pragmatism is holding the trump card. Don’t let the perfect be the enemy of the good!

For many of these ISVs, the end goal will be to re-write as a “cloudy” application (and thus reap all of the cost savings to both them, and their customers), but the direct path may not be the most cost effective.


Switching Hats

Now let’s take off my hat, and put on the Enterprise-end-user hat. To understand the reaction wearing this hat, I invite you to read Frank’s blog post.

As Frank points out, when the original post is read as an enterprise end-user (or even an enterprise developer), a lot of the arguments do not make any sense. This is because enterprises and ISVs are different beasts.

It’s Inflexible

An enterprise knows its requirements. It knows what local data centers it will need, and it controls all of its end-users.

An enterprise does not have to consider what would happens if a new customer appeared in a country that had strict data laws, and there was no data center for your platform located there.

An enterprise does not have to consider that they might suddenly find out their enterprise application needs to be HIPAA compliant because they were able to score a new customer in the health care space. (I am not saying they would not ever have to be HIPAA compliant, but they would be better able to plan for it).

It’s Less Secure

The question of multi-tenancy within the application is meaningless here. All the data in that application is for that enterprise. There no risk of having your enterprises’ data accidently exposed to another enterprise due to your programming or configuration error.

It’s Less Powerful

An enterprise is in control of all of its users, and is able to limit functionality by mandate. An example of this is IT departments that often mandate “This is our list of supported browsers”, or “This is our list of supported devices”.

Most ISVs are not in a position to make mandates to their users. If they cannot support a certain feature, they lose customers. That customer will not care if the excuse is, “My underlying platform does not support that.”

It May Be More Costly

From time to time, enterprises need to do overhauls of their applications. While these are disruptive, there is nothing you can do except grit your teeth and wait for the disruption to pass.

It is much harder for an ISV to tell their customers:

“We have to do a major internal rewrite. This means our next release will contain almost no new features, and will probably be late.”

(In reality, ISVs still actually have to do this, but they try to mitigate it by doing it in smaller chunks.)


Taking the Hats Off

Several months back, there was a blog post at the SAP Community Network from Richard Hirsch entitled What is the relationship between Sybase’s ‘SQL Anywhere OnDemand Edition’ and SAP’s other OnDemand offerings?. After delving into the question, he concluded:

  1. There were other use cases in the market beyond those that were being met by SAP OnDemand offerings on which I usually concentrate (OnDemand Core, OnDemand Edge, SAP NetWeaver OnDemand, etc)


  • The SaaS market is varied / more complicated than many assume.


I think this hits the nail on the head. The original post was targeted at the group outlined in his first point.

The second point is a good reminder for me. I spend so much of my day wearing my own hat (after all, it is comfortable), and I failed to anticipate how these ideas would be interpreted if read wearing a different hat. I apologize for the confusion it has caused.


Eric Farrar

About Eric Farrar

Eric Farrar is a Senior Product Manager at SAP. His specialties include cloud computing, software development, product management, mobile applications and solution selling.



Why 3D Printed Food Just Transformed Your Supply Chain

Hans Thalbauer

Numerous sectors are experimenting with 3D printing, which has the potential to disrupt many markets. One that’s already making progress is the food industry.

The U.S. Army hopes to use 3D printers to customize food for each soldier. NASA is exploring 3D printing of food in space. The technology could eventually even end hunger around the world.

What does that have to do with your supply chain? Quite a bit — because 3D printing does more than just revolutionize the production process. It also requires a complete realignment of the supply chain.

And the way 3D printing transforms the supply chain holds lessons for how organizations must reinvent themselves in the new era of the extended supply chain.

Supply chain spaghetti junction

The extended supply chain replaces the old linear chain with not just a network, but a network of networks. The need for this network of networks is being driven by four key factors: individualized products, the sharing economy, resource scarcity, and customer-centricity.

To understand these forces, imagine you operate a large restaurant chain, and you’re struggling to differentiate yourself against tough competition. You’ve decided you can stand out by delivering customized entrees. In fact, you’re going to leverage 3D printing to offer personalized pasta.

With 3D printing technology, you can make one-off pasta dishes on the fly. You can give customers a choice of ingredients (gluten-free!), flavors (salted caramel!), and shapes (Leaning Towers of Pisa!). You can offer the personalized pasta in your restaurants, in supermarkets, and on your ecommerce website.

You may think this initiative simply requires you to transform production. But that’s just the beginning. You also need to re-architect research and development, demand signals, asset management, logistics, partner management, and more.

First, you need to develop the matrix of ingredients, flavors, and shapes you’ll offer. As part of that effort, you’ll have to consider health and safety regulations.

Then, you need to shift some of your manufacturing directly into your kitchens. That will also affect packaging requirements. Logistics will change as well, because instead of full truckloads, you’ll be delivering more frequently, with more variety, and in smaller quantities.

Next, you need to perfect demand signals to anticipate which pasta variations in which quantities will come through which channels. You need to manage supply signals source more kinds of raw materials in closer to real time.

Last, the source of your signals will change. Some will continue to come from point of sale. But others, such as supplies replenishment and asset maintenance, can come direct from your 3D printers.

Four key ingredients of the extended supply chain

As with our pasta scenario, the drivers of the extended supply chain require transformation across business models and business processes. First, growing demand for individualized products calls for the same shifts in R&D, asset management, logistics, and more that 3D printed pasta requires.

Second, as with the personalized entrees, the sharing economy integrates a network of partners, from suppliers to equipment makers to outsourced manufacturing, all electronically and transparently interconnected, in real time and all the time.

Third, resource scarcity involves pressures not just on raw materials but also on full-time and contingent labor, with the necessary skills and flexibility to support new business models and processes.

And finally, for personalized pasta sellers and for your own business, it all comes down to customer-centricity. To compete in today’s business environment and to meet current and future customer expectations, all your operations must increasingly revolve around rapidly comprehending and responding to customer demand.

Want to learn more? Check out my recent video on digitalizing the extended supply chain.


Hans Thalbauer

About Hans Thalbauer

Hans Thalbauer is the Senior Vice President, Extended Supply Chain, at SAP. He is responsible for the strategic direction and the Go-To-Market of solutions for Supply Chain, Logistics, Engineering/R&D, Manufacturing, Asset Management and Sustainability at SAP.

How to Design a Flexible, Connected Workspace 

John Hack, Sam Yen, and Elana Varon

SAP_Digital_Workplace_BRIEF_image2400x1600_2The process of designing a new product starts with a question: what problem is the product supposed to solve? To get the right answer, designers prototype more than one solution and refine their ideas based on feedback.

Similarly, the spaces where people work and the tools they use are shaped by the tasks they have to accomplish to execute the business strategy. But when the business strategy and employees’ jobs change, the traditional workspace, with fixed walls and furniture, isn’t so easy to adapt. Companies today, under pressure to innovate quickly and create digital business models, need to develop a more flexible work environment, one in which office employees have the ability to choose how they work.

SAP_Digital_Emotion_BRIEF_image175pxWithin an office building, flexibility may constitute a variety of public and private spaces, geared for collaboration or concentration, explains Amanda Schneider, a consultant and workplace trends blogger. Or, she adds, companies may opt for customizable spaces, with moveable furniture, walls, and lighting that can be adjusted to suit the person using an unassigned desk for the day.

Flexibility may also encompass the amount of physical space the company maintains. Business leaders want to be able to set up operations quickly in new markets or in places where they can attract top talent, without investing heavily in real estate, says Sande Golgart, senior vice president of corporate accounts with Regus.

Thinking about the workspace like a designer elevates decisions about the office environment to a strategic level, Golgart says. “Real estate is beginning to be an integral part of the strategy, whether that strategy is for collaborating and innovating, driving efficiencies, attracting talent, maintaining higher levels of productivity, or just giving people more amenities to create a better, cohesive workplace,” he says. “You will see companies start to distance themselves from their competition because they figured out the role that real estate needs to play within the business strategy.”

The SAP Center for Business Insight program supports the discovery and development of  new research-­based thinking to address the challenges of business and technology executives.


Sam Yen

About Sam Yen

Sam Yen is the Chief Design Officer for SAP and the Managing Director of SAP Labs Silicon Valley. He is focused on driving a renewed commitment to design and user experience at SAP. Under his leadership, SAP further strengthens its mission of listening to customers´ needs leading to tangible results, including SAP Fiori, SAP Screen Personas and SAP´s UX design services.


Innovation Without Boundaries: Why The Cloud Matters

Michael Haws

Is it possible to innovate without boundaries?

Of course – if you are using the cloud. An actual cloud doesn’t have any boundaries. It’s fluid. But more important, it can provide the much-needed precipitation that brings nature to life. So it is with cloud technology – but it’s your ideas that can grow and transform your business.USA --- Clouds, Heaven --- Image by © Ocean/Corbis

Running your business in the cloud is no longer just a consideration during a typical use-case exercise. Business executives are now faced with making decisions on solutions that go beyond previous limitations with cloud computing. Selecting the latest tools to address a business process gap is now less about features and more about functionality.

It doesn’t matter whether your organization is experienced with cloud solutions or new to the concept. Cloud technology is quickly becoming a core part of addressing the needs of a growing business.

5 considerations when planning your journey to the cloud

How can your organization define its successful path to the cloud? Here are five things you should consider when investigating whether a move to the cloud is right for you.

1. Understanding the cloud is great, but putting it into action is another thing.

For most CIOs, putting a cloud strategy on paper is new territory. Cloud computing is taking on new realms: Pure managed services to software-as-a-service (SaaS). Just as legacy computing had different flavors, so does cloud technology.

2. There is more than one way to innovate in the cloud.

Alignment with an open cloud reference architecture can help your CIO deliver on the promises of the cloud while using a stair-step approach to cloud adoption – from on-premise to hybrid to full cloud computing. Some companies find their own path by constantly reevaluating their needs and shifting their focus when necessary – making the move from running a data center to delivering real value to stakeholders, for example.

3. The cloud can help accelerate processes and lower cost.

By recognizing unprecedented growth, your organization can embark on a path to significant transformation that powers greater agility and competitiveness. Choose a solution set that best meets your needs, and implement and support it moving forward. By leveraging the cloud to support the chosen solution, ongoing maintenance, training, and system issues becomes the cloud provider’s responsibility. And for you, this offers the freedom to focus on the core business.

4. You can lock down your infrastructure and ensure more efficient processes.

Do you use a traditional reporting engine against a large relational database to generate a sequential batched report to close your books at quarter’s end? If so, you’re not alone. Sure, a new solution with new technology may be an obvious improvement. But how valuable to your board will you become when you reduce the financial closing process by 1–3 days? That’s the beauty of the cloud: You can accelerate the deployment of your chosen solution and realize ROI quickly – even before the next full reporting period.

5. The cloud opens the door to new opportunity in a secure environment.

For many companies, moving to the cloud may seem impossible due to the time and effort needed to train workers and hire resources with the right skill sets. Plus, if you are a startup in a rural location, it may not be as easy to attract the right talent as it is for your Silicon Valley counterparts. The cloud allows your business to secure your infrastructure as well as recruit and onboard those hard-to-find resources by applying a managed services contract to run your cloud model

The cloud means many things to different people. What’s your path?

With SAP HANA Enterprise Cloud service, you can navigate the best path to building, running, and operating your own cloud when running critical business processes. Find out how SAP HANA Enterprise Cloud can deliver the speed and resources necessary to quickly validate and realize solid ROI.

Check out the video below or visit us at

Connect with us on Twitter: @SAPServices


Michael Haws

About Michael Haws

Michael Haws is the Vice President of HANA Enterprise Cloud at SAP. His specialties include Enterprise Resource Planning Software & Services, Onshore, Nearshore, Offshore--Application, Infrastructure and Business Process Outsourcing.


Consumers And Providers: Two Halves Of The Hybrid Cloud Equation

Marty McCormick

Long gone are the days of CIOs and IT managers freely spending money to move their 02 Jun 2012 --- Young creatives having lunch and conversation. --- Image by © Hero/Corbisexisting systems to the cloud without any real business justification just to be part of the latest hype. As cloud deployments are becoming more prevalent, IT leaders are now tasked with proving the tangible benefits of adopting a cloud strategy from an operational, efficiency, and cost perspective. At the same time, they must balance their end users’ increasing demand for access to more data from an ever-expanding list of public cloud sources.

Lately, public cloud systems have become part of IT landscapes both in the form of multi-tenant systems, such as software-as-a-service (SaaS) offerings and data consumption applications such as Twitter. Along with the integration of applications and data outside of the corporate domain, new architectures have been spawned, requiring real-time and seamless integration points.  As shown in the figure below, these hybrid clouds – loosely defined as the integration of data from systems in both public and private clouds in a unified fashion – are the foundation of this new IT architecture.


Not only has the hybrid cloud changed a company’s approach to deploying new software, but it has also changed the way software is developed and sold from a provider’s perspective.

The provider perspective: Unifying development and operations

Thanks to the hybrid cloud approach, system administrators and developers are sitting side by side in an agile development model known as Development and Operations (DevOps). By increasing collaboration, communication, innovation, and problem resolution, development teams can closely collaborate with system administrators and provide a continuous feedback loop of both sides of the agile methodology.

For example, operations teams can provide feedback on reported software bugs, software support issues, and new feature requests to development teams in real time. Likewise, development teams develop and test new applications with support and maintainability as a key pillar in design.
After seeing the advantages realized by cloud providers that have embraced this approach long ago, other companies that have traditionally separated these two areas are now adopting the DevOps model.

The consumer perspective: Moving to the cloud on its own terms

From the standpoint of the corporate consumer, hybrid cloud deployments bring a number of advantages to an IT organization. Specifically, the hybrid approach allows companies to move some application functionality to the cloud at their own pace.
Many applications naturally lend themselves to public cloud domains given their application and data requirements. For most companies, HR, indirect procurement, travel, and CRM systems are the first to be deployed in a public cloud. This approach eliminates the requirement for building and operating these applications in house while allowing IT areas to take advantage of new features and technologies much faster.

However, there is one challenge consumers need to overcome: The lack of capabilities needed to extend these applications and meet business requirements when the standard offering is often insufficient. Unfortunately, this tempts organizations to create extensive custom applications that replicate information across a variety of systems to meet end user requirements. This development work can offset the cost benefits of the initial cloud application, especially when you consider the upgrades and support required to maintain the application.

What this all means to everyone involved in the hybrid cloud

Given these two perspectives, on-premise software providers are transforming themselves so they can meet the ever-evolving demands of today’s information consumer. In particular, they are preparing for these unique challenges facing customers and creating a smooth journey to a hybrid cloud.

Take SAP, for example. By adopting a DevOps model to break down a huge internal barrier and allowing tighter collaboration, the company has delivered a simpler approach to hybrid cloud deployments through the SAP HANA Cloud Platform for extending applications and SAP HANA Enterprise Cloud for hosting solutions.

Find out how these two innovations can help you implement a robust and secure hybrid cloud solution:
SAP HANA Cloud Platform
SAP HANA Enterprise Cloud


Marty McCormick

About Marty McCormick

Marty McCormick is the Lead Technical Architect, Managed Cloud Delivery, at SAP. He is experienced in a wide range of SAP solutions, including SAP Netweaver SAP Portal, SAP CRM, SAP SRM, SAP MDM, SAP BI, and SAP ERP.