Building Multi-Tenant SaaS Architectures

Chapter 1. The SaaS Mindset

I’ve worked with a number of teams that were building software-as-a-service (SaaS) solutions. When I sit down with them to map out their path to SaaS, they tend to start out with what seems like a reasonable, high-level view of what it means to be SaaS. However, as I go a layer deeper and get into the details of their solution, I often discover significant variations in their vision. Imagine, for example, someone telling you they want to construct a building. While we all have some notion of a building having walls, windows, and doors, the actual nature of these structures can vary wildly. Some teams might be envisioning a skyscraper, and others might be building a house.

It’s kind of natural for there to be confusion around what SaaS looks like. As is the case in all technology realms, the SaaS universe is continually evolving. The emergence of the cloud, shifting customer needs, and the economics of the software domain are in constant motion. How we defined SaaS yesterday may not be the way we’ll define it today. The other part of the challenge here is that the scope of SaaS goes well beyond the technical. It is, in many respects, a mindset that spans all the dimensions of a SaaS provider’s organization.

With that in mind, the natural place to start this journey is by clarifying how I define SaaS and how I think this definition shapes our approach to architecting, designing, and building a SaaS solution. The goal in this chapter is to build a foundational mental model that will reduce some of the confusion about what it means to be SaaS. We’ll move beyond some of the vague notions of SaaS and, at least for the scope of this book, attach more concrete guiding principles to the definition of SaaS that will shape the strategies that we’ll explore in the coming chapters.

To get there, we’ll need to look at the forces that motivated the move to SaaS and see how these forces directly influenced the resulting architectural models. Following this evolution will provide a more concrete view into the foundational principles that are used to create a SaaS solution that realizes the full value proposition of SaaS, blending the technical and business parameters that are at the core of developing modern SaaS environments. It’s essential for SaaS architects to understand that SaaS is not a technology-first mindset. A SaaS architect doesn’t design a multi-tenant architecture first, then figure out how the business strategy layers on top of that. Instead, the business and technology work together to find the best intersection of business goals and multi-tenant solutions that will realize those strategies. This theme will be with us throughout this book.

While you may feel comfortable with what SaaS means to you, it’s possible that the foundational concepts we’ll explore here might challenge your view of SaaS and the terminology we use to describe SaaS environments. So, while it may be tempting to treat this chapter as optional, it may be one of the most important chapters in the book. It’s not just an introduction; it’s about creating a common vocabulary and mental model that will be woven into the architecture, coding, and implementation strategies that we’ll be covering throughout this book.

Where We Started

Before we can dig into defining SaaS, we need to understand where this journey started and the factors that have driven the momentum of the SaaS delivery model. Let’s start by looking at how software has been traditionally built, operated, and managed. Generally, pre-SaaS systems were typically delivered in an “installed software” model where customers played a role in installation and setup of their software. The customer’s IT team might install it on some vendor-provided environment or they might run it on their own infrastructure. In this mode, the management and operation of these environments, to some degree, could be pushed to the customer’s IT team. A professional services team could also play some role during the installation, customization, and configuration of the customer’s environment.

In this model, software development teams tended to be more removed from these delivery and setup details. They were more focused on continually building out the functional capabilities of their solutions. Delivery and operations were often on the side of the wall and handled somewhat downstream of the day-to-day development efforts.

Figure 1-1 provides a conceptual view of the footprint of the traditional software delivery model.

Figure 1-1. The installed software model

In the top left of Figure 1-1, you’ll see I have introduced an independent software vendor (ISV) that represents the entity selling software to its customers. I’ve also shown two customers that currently own the ISV’s software, Customers 1 and 2. Each of these customers is running specific versions of the ISV’s product. As part of their onboarding, they also required one-off customizations to the product that were addressed by the ISV’s professional services team. We also have other customers that may be running different versions of our product that may or may not have any customizations.

As each new customer is onboarded, the provider’s operations organization may need to create focused teams that can support the day-to-day needs of these customer environments. These teams might be dedicated to an individual customer or support a cross-section of customers.

This classic mode of software delivery is a much more sales-driven model, where the business focuses on acquiring customers and handing them off to technology teams to address the specific needs of each incoming customer. You can imagine how this dynamic shapes the overall culture and development cycle of the experience. How your product is built, how new features are rolled out, how you think about customization—these are all areas influenced by the nature of this approach. The mindset here is one where landing a deal can take precedence over the need for agility, scale, and operational efficiency. These solutions are also frequently sold with long-term contracts that limit a customer’s ability to easily move to any other vendor’s offering.

The distributed and varying nature of these customer environments often slows the release and adoption of new features. Customers tend to have control in these settings, often dictating how and when they might upgrade to a new version. The complexity of testing and deploying these environments could become unwieldy, pushing vendors toward quarterly or semi-annual releases.

To be fair, building and delivering software using this model is and will continue to be a perfectly valid approach for some businesses. The legacy, compliance, and business realities of any given domain might align well to this model. However, for many, this mode of software delivery introduces a number of challenges. At its core, this approach focuses more on being able to sell customers whatever they need in exchange for trade-offs around scale, agility, and cost/operational efficiency.

On the surface, these trade-offs may not seem all that significant. If you have a limited number of customers and you’re only landing a few a year, this model could be entirely adequate. You would still have inefficiencies, but they would be far less prominent. Consider, however, a scenario where you have a significant installed base and are looking to grow your business rapidly. In that mode, the pain points of this approach begin to represent a real problem for many software vendors.

Operational and cost efficiencies are often amongst the first areas where companies using this model start to feel the pain. The incremental overhead of supporting each new customer begins to have real impacts on the business, eroding margins and continually adding complexity to the operational profile of the business. Each new customer could require more support teams, more infrastructure, and more effort to manage the one-off variations that accompany each customer installation. In some cases, companies actually reach a point where they’ll intentionally slow their growth because of the operational burdens of this model.

The bigger issue here, though, is how this model impacts agility, competition, growth, and innovation. By its very nature, this model is anything but nimble. Allowing customers to manage their own environments, supporting separate versions for each customer, enabling one-off customization—these are all areas that undermine speed and agility. Imagine what it would mean to roll out a new feature in these environments. The time between having the idea for a feature, iterating on its development, and getting it in front of all your customers is often a slow and deliberate process. By the time a new feature arrives, customer and market needs may have already shifted. This also can impact the competitive footprint of these companies, limiting their ability to rapidly react to emerging solutions that are built around a lower friction model.

While the operational and development footprint was becoming harder to scale, the needs and expectations of customers were also shifting. Customers have become less focused on retaining the ability to manage or control their environments. Instead, they’re more interested in maximizing the value they can extract from their software. They are increasingly demanding lower friction experiences that can continually innovate to meet their needs, giving them more freedom to move between solutions based on the evolving needs of their businesses.

Customers are also more drawn to pricing models that better align with their value and consumption profile. In some cases, they’re looking for the flexibility of subscription and/or pay-as-you-go pricing models.

You can see the natural tension that’s at play here. For many, the classic delivery model simply doesn’t align well with their ability to scale or grow their business and meet the evolving needs of their customers. The emergence of the cloud also played a key role here. The cloud model fundamentally altered the way companies looked at hosting, managing, and operating their software. The pay-as-you-go nature and operational model of the cloud shifted the mindset of the industry, placing a greater emphasis on agility and economies of scale. Together, these forces motivated software providers to rethink how they build, deliver, operate, and sell their solutions.

The Move to a Unified Model

By now, the basic challenges of the traditional model should be clear. While some organizations were struggling with this model, others already understood this approach would simply not scale economically or operationally. If you are a B2B ISV with thousands of customers, for example, it’s unlikely that your business would be able to support a model where each customer had to be separately supported, managed, and operated.

The answer, for many, was to move to a model that unified more of the experience, reducing the complexity and cost that naturally came with supporting the per-customer model. This is where we saw teams adopting a shared infrastructure model that would allow them to scale their business and streamline their operational model more effectively.

This shift to a more unified, shared model opened a range of new opportunities for software providers. Figure 1-2 provides a conceptual view of a simplified shared infrastructure SaaS environment.

Figure 1-2. A shared infrastructure SaaS model

In Figure 1-2, you’ll see a simplified view of the traditional notion of SaaS. You’ll notice that we’ve completely moved away from the distributed, one-off, custom nature of the classic model we saw in Figure 1-1. Instead, we’ve shifted to a unified strategy where all the system’s application services and infrastructure are shared by the customers. You’ll also see that I have replaced the term “customer” with “tenant.” We’ll get deeper into the notion of tenancy in Chapter 2. The fundamental idea is that, as we move to this unified mindset, we look at our environment differently. It is now one set of resources that is shared and occupied by one or more consumers. The idea is that these consumers represent temporary occupants of your environment, consuming only those resources they need—hence the term “tenant.”

Moving an application into a shared infrastructure model removes many of the downsides that come with having separate customer environments. Now, with everything being shared, we have one set of resources that can be collectively scaled, managed, and operated. On the righthand side of Figure 1-2, you’ll see that I’ve added a box to represent the management, operations, and deployment of this environment. Imagine how this would simplify the deployment of updates. With shared infrastructure, your deployment automation would simply deploy the update to this unified SaaS environment, and all of your tenants would immediately have access to the changes. Gone is the idea of separately deployed, versioned, managed, and operated customer environments.

The upside of shared infrastructure extends into nearly every aspect of a software business. It can streamline the aggregation and collection of operational telemetry. It can simplify the complexity of your DevOps automation. It certainly makes onboarding new tenants easier. Perhaps the biggest upside is the cost efficiencies that could come with shared infrastructure. Being able to correlate consumption of infrastructure with actual tenant activity enables teams to maximize margins and achieve economies of scale.

You can see how this model had massive appeal to those organizations that were struggling with the cost and operational challenges of the classic model. In addition to unifying the experience, it also brought a new level of agility to these environments. Built right, these environments create opportunities to release new features and capabilities at a much faster pace, allowing organizations to be more nimble in reacting and responding to customer/market needs. The nature of this model also creates new growth opportunities for some ISVs, allowing them to add new tenants at a faster pace without eroding their margins and absorbing added operational overhead. The elastic, pay-as-you-go nature of cloud infrastructure also aligns nicely with this model, supporting the pricing and scaling models that fit naturally with the elasticity of the cloud.

It’s worth noting that this move to shared infrastructure also introduces a range of new challenges. As you move through this book, you’ll see all the nuances and complexity that come with having shared infrastructure. Supporting shared infrastructure will directly influence the security, performance, scale, availability, and resilience profile of your SaaS environment. These factors will have a distinct impact on how you approach the design and implementation of your SaaS environment.

Note

This notion of having all tenants running the same version of your offering represents a common litmus test for SaaS environments. It is foundational to enabling many of the business benefits that are at the core of adopting a SaaS delivery model.

To create a unified experience, we must also introduce a new set of cross-cutting components that provide all the functionality that’s needed to centrally manage, operate, and deploy a SaaS application. Carving out these separate components is essential to building a successful and scalable SaaS business—even if your application doesn’t have shared infrastructure. In reality, these components are at the core of driving the agility, innovation, and efficiency goals of SaaS companies. To better understand this point, let’s look at a slightly different view of a SaaS environment (shown in Figure 1-3).

Figure 1-3. Building cross-cutting SaaS capabilities

At the center of Figure 1-3, you’ll see a placeholder for your SaaS application experience. This is where the various components of your SaaS application are deployed. It’s here that you would find the infrastructure of your application. Around the application are a set of components that are needed to support the broader needs of your SaaS environment. At the top, for example, I’ve highlighted onboarding and identity, which provide all the functionality to introduce a new tenant into your system. On the left, you’ll see the placeholders for the SaaS deployment and management functionality. And, on the right, you’ll see fundamental concepts like billing, metering, metrics, and analytics.

Now, for many SaaS builders, it’s tempting to view these surrounding components as secondary, less critical elements of their SaaS architecture. In fact, I’ve worked with teams that have chosen to defer the introduction of these components/services, putting all their initial energy and effort into creating their multi-tenant applications.

While getting the application architecture right is certainly an important part of your SaaS model, the success of your SaaS business will be heavily influenced by the capabilities of these surrounding components. These capabilities are at the core of enabling much of the operational efficiency, growth, innovation, and agility goals that are motivating companies to adopt a SaaS model. So, these components—which are common to all SaaS environments—must be put front and center when you are building your SaaS solution. This is why I have always encouraged SaaS teams to start their SaaS development with them. It’s these building blocks—which have nothing to do with the functionality of your application—that are going to have a significant influence on the SaaS footprint of your architecture, design, code, and business.

This should highlight the fact that there are multiple dimensions to the SaaS efficiency and agility story. Part of our efficiency is realized through the services that are shown here, and part of it achieved through the strategies you apply to your application architecture. If your application architecture shares infrastructure, it can add more efficiency and economies of scale to your environment. The key is that we must have these surrounding services represent the foundational elements of our unified model. Then, from there, we can think about how/if the application architecture can also be optimized to maximize efficiency and agility.

Redefining Multi-Tenancy

Up to this point, I’ve avoided introducing the idea of multi-tenancy. It’s a term that is used heavily in the SaaS space and will appear throughout the remainder of this book. However, it’s a term that we must approach gracefully. The idea of multi-tenancy comes with lots of attached baggage and, before sorting it out, I wanted to create some foundation for the fundamentals that have driven companies toward the adoption of the SaaS delivery model. The other part of the challenge here is that the notion of multi-tenancy—as we’ll define it in this book—will move beyond some of the traditional definitions that are typically attached to this term.

For years, in many circles, the term “multi-tenant” was used to convey the idea that some resource was being shared by multiple tenants. This could apply in many contexts. We could say that some piece of cloud infrastructure, for example, could be deemed multi-tenant because it allows tenants to share bits of its underlying infrastructure. Many services running in the cloud may be running in a multi-tenant model to achieve their economies of scale. As a cloud consumer, this may be happening entirely outside of your view. Even in self-hosted environments, teams can build solutions where their compute, databases, and other resources are shared by tenants. This creates a very tight connection between multi-tenancy and the idea of a shared resource. In fact, in this context, this is a perfectly valid notion of multi-tenancy.

Now, as we start thinking about SaaS environments, it’s entirely natural for us to bring the mapping of multi-tenancy with us. After all, SaaS environments do share infrastructure, and that sharing of infrastructure is certainly valid to label as being multi-tenant.

To better illustrate this point, let’s look at a sample SaaS model that brings together the concepts that we’ve been discussing in this chapter. The image in Figure 1-4 provides a view of a sample multi-tenant SaaS environment.

Figure 1-4. A sample multi-tenant environment

For this example, we’ve landed the shared infrastructure of our application services inside a surrounding set of microservices that are used to manage and operate all the moving parts of our SaaS environment. Assuming that all of our tenants are sharing their infrastructure (compute, storage, and so on), this would still fit with the classic definition of multi-tenancy, and it’s not uncommon for SaaS providers to define and deliver their solution following this pattern.

The challenge is that SaaS environments don’t exclusively conform to this model. Suppose, for example, I create a SaaS environment that looks like Figure 1-5.

Figure 1-5. Multi-tenancy with shared and dedicated resources

Notice that we’ve morphed the footprint of some of our application microservices. The Product microservice is unchanged. Its compute and storage infrastructure are still shared by all tenants. However, as we move to the Order microservice, you’ll see that we’ve mixed things up a bit. Our domain, performance, and/or security requirements may have required us to separate out the storage for each tenant. So, the compute of our Order microservice is still shared, but we have separate databases for each tenant.

Finally, our Fulfillment microservice has also shifted. Our requirements pushed us toward a model where each tenant is running dedicated compute resources. In this case, though, the database is still shared by all tenants.

This architecture has certainly added a new wrinkle to our notion of multi-tenancy. If we’re sticking to the purest definition of multi-tenancy, we wouldn’t really be able to say everything running here conforms to the original definition of multi-tenancy. The storage of the Order service, for example, is not sharing any infrastructure between tenants. The compute of our Fulfillment microservices is also not shared, but the database for this service is shared by all tenants.

Blurring these multi-tenant lines is common in the SaaS universe. When you’re composing a SaaS environment, you’re not sticking to any one absolute definition of multi-tenancy; you’re picking the combinations of shared and dedicated resources that best align with the business and technical requirements of your system. This is all part of optimizing the footprint of your SaaS architecture around the needs of the business.

Even though the resources here are not shared by all tenants, the fundamentals of the SaaS principles we outlined earlier are still valid. For example, this environment would not change our application deployment approach. All tenants in this environment would still be running the same version of the product. Also, the environment would still be onboarded, operated, and managed by the same set of shared services we relied on in our prior example. This means that we’re still extracting much of the operational efficiency and agility from this environment that would have been achieved in a fully shared infrastructure (with some caveats).

To drive this point home, let’s look at a more extreme example. Suppose we have a SaaS architecture that resembles the model shown in Figure 1-6. In this example, the domain, market, and/or legacy requirements have required us to have all compute and storage running in a dedicated model where each tenant has a completely separate set of infrastructure resources.

Figure 1-6. A multi-tenant environment with fully dedicated resources

While our tenants aren’t sharing infrastructure in this model, you’ll see that they continue to be onboarded, managed, and operated through the same set of shared capabilities that have spanned all of our examples. That means that all tenants are still running the same version of the software and they are still being managed and operated collectively.

This may seem like an unlikely scenario. However, in the wild, SaaS providers may have any number of different factors that might require them to operate in this model. Migrating SaaS providers often employ this model as a first stepping stone to SaaS. Other industries may have such extreme isolation requirements that they’re not allowed to share infrastructure. There’s a long list of factors that could legitimately land a SaaS provider in this model.

So, given this backdrop, it seems fair to ask ourselves how we want to define multi-tenancy in the context of a SaaS environment. Using the literal shared infrastructure definition of multi-tenancy doesn’t seem to map well to the various models that can be used to deploy tenant infrastructure. Instead, these variations in SaaS models seem to demand that we evolve our definition of what it means to be multi-tenant.

For the scope of this book, at least, the term “multi-tenant” will definitely be extended to accommodate the realities outlined here. As we move forward, multi-tenant will refer to any environment that onboards, deploys, manages, and operates tenants through a single, unified experience. The sharedness of any infrastructure will have no correlation to the term “multi-tenancy.”

In the ensuing chapters, we’ll introduce new terminology that will help us overcome some of the ambiguity that is attached to multi-tenancy.

Avoiding the “Single-Tenant” Term

Generally, whenever architects and builders refer to something as multi-tenant, there’s a natural tendency to assume there must be some corresponding notion of what it means to be single-tenant. The idea of single tenancy seems to get mapped to those environments where no infrastructure is shared by tenants.

While I follow the logic of this mindset, the term doesn’t really seem to fit anywhere in the model of SaaS outlined here. If you look back to Figure 1-6, where our solution had no shared infrastructure, I noted that we would still label this a multi-tenant environment since all tenants were still running the same version and being managed or operated collectively. Labeling this a single-tenant environment would undermine the idea that we aren’t somehow realizing the benefits of the SaaS model.

With this in mind, the term “single-tenant” will not be used at any point beyond this chapter. Every design and architecture we discuss will be deemed a multi-tenant architecture, and we’ll attach new terms to describe the various deployment models that will still allow us to convey if and how infrastructure is being shared within a given SaaS environment. The general goal here is to disconnect the concept of multi-tenancy from the sharing of infrastructure and use it as a broader term to characterize any environment that is built, deployed, managed, and operated in a SaaS model.

This is less about what SaaS is or is not and more about establishing a vocabulary that aligns better with the concepts we’ll be exploring throughout this book.

Where Are the Boundaries of SaaS?

We’ve laid a foundation for what it means to be SaaS, but there are lots of nuances that we haven’t really talked about. For example, suppose your SaaS application requires portions of the system to be deployed in some external location, or imagine scenarios where your application has dependencies on other vendors’ solutions. Maybe you are using a third-party billing system, or your data must reside in another environment. There are any number of different reasons why you may need to have parts of your overall SaaS environment hosted somewhere that may not be entirely under your control.

So, how would this more distributed footprint fit with the idea of having a single, unified experience for all of your tenants? After all, having full control over all the moving parts of your system certainly maximizes your ability to innovate and move quickly. At the same time, it’s impractical to think that some SaaS providers won’t face domain and technology realities that require them to support externally hosted components, tools, or technologies.

This is where we don’t want to be too extreme with our definition of SaaS. To me, the boundary is more around how these external dependencies are configured, managed, and operated. If their presence is entirely hidden from your tenants and they are still managed and operated through your centralized experience, this is still SaaS to me. It may introduce new complexities, but it doesn’t change the spirit of the SaaS model we’re trying to build.

Where this gets more interesting is when SaaS providers rely on external resources that are in direct view of their tenants. If, for example, my SaaS solution stores data in some tenant-hosted database, that’s where things get more dicey. Now, you may have a dependency on infrastructure that is not entirely under your control. Updating this database, changing its schema, managing its health—these get more complicated in this model. This is where we start to ask questions about whether this external resource is breaking the third wall of SaaS, exposing tenants to infrastructure and creating expectations or dependencies that undermine the agility, operations, and innovation of your SaaS environment.

My general rule of thumb here (with some exceptions) is that we’re providing a service experience. In a service model, our tenants’ view is limited to the surface of our service. The tools, technologies, and resources that are used to bring that service to life should be entirely hidden from our tenants. In many respects, this is the hard barrier that prevents our system from falling back into patterns that might lead to one-off dependencies and variations.

The Managed Service Provider Model

There’s one last wrinkle that we need to address as we try to refine our view of what it means to be a multi-tenant SaaS environment. Some organizations have opted into what’s referred to as a Managed Service Provider (MSP) model. In some cases, they’ll categorize MSP as a variant of SaaS. This has created some confusion in the SaaS domain. To better understand the challenges here, let’s start by looking at an MSP environment and see how and where it fits in this discussion. Figure 1-7 provides a conceptual view of an MSP environment.

This model resembles the classic installed software model that we outlined earlier. At the bottom of this diagram, you’ll see a collection of customers that are running various versions of a software vendor’s product. Each one of these customers will be running in its own infrastructure or environment.

With MSP, though, we’ll try to get efficiencies and economies of scale out of moving the operations to a centralized team or entity. This is the service that these MSPs provide. They often own responsibility for installing, managing, and supporting each of these customers, attempting to extract some scale and efficiency out of tooling and mechanisms that they use to operate these customer environments.

Figure 1-7. A Managed Service Provider (MSP) model

I’ve also represented the software vendor at the top of the diagram. This is here to convey the idea that the software provider may have third-party relationships with one or more MSPs that are managing their customer environments.

You can see how some might equate the MSP model to SaaS. After all, it does seem to be trying to provide a unified managed and operations experience for all customers. However, if you look back at the principles that we used to describe SaaS, you can see where there are substantial gaps between the MSP model and SaaS. One of the biggest differences is that customers are being allowed to run separate versions. So, while there may be some attempts to centralize management and operations, the MSP is going to have to have one-off variations in their operational experience to support the different footprints of each customer environment. This may require dedicated teams; at a minimum, it will mean having teams that can deal with the complexities of supporting the unique needs of each customer. Again, the MSP model adds lots of value and certainly creates efficiencies, but it’s definitely different than having a single pane of glass that gets its efficiencies from having customers run a single version of a product and, in many cases, realizing economies of scale from sharing some or all of their infrastructure. At some level in the MSP model, you’re likely to still inherit aspects of the pain that comes with one-off customer variations. MSPs can introduce some measures to offset some of the challenges, but they’ll still face the operational and agility complexities that come with supporting unique, one-off needs of separate customer environments.

The other difference relates more to how SaaS teams are structured and operated. Generally, in a SaaS organization, we’re attempting to avoid drawing hard lines between operations teams and the rest of the organization. We want operations, architects, product owners, and the various roles of our team working closely together to continually evaluate and refine the service experience of their offering.

This typically means that these teams are tightly connected. They’re equally invested in understanding how their tenants are consuming their systems, how they’re imposing load, how they’re onboarding, and a host of other key insights. SaaS businesses want and need to have their fingers on the pulse of their systems. This is core to driving the success of the business and being connected more directly to the overall tenant experience. So, while this is a less concrete boundary, it still represents an important difference between SaaS and MSP.

Now, it’s important to note that MSP is an entirely valid model. It often represents a good fit for some software providers. MSP can even be a stepping stone for some SaaS providers, providing access to some efficiencies while the team continues to push forward toward its SaaS delivery model. The key is that we have a clear understanding of the boundaries between SaaS and MSP and avoid viewing SaaS and MSP as somehow being synonymous.

At Its Core, SaaS Is a Business Model

By now you should have a better sense of how we characterize what it means to be SaaS. It should be clear that SaaS is very much about creating a technology, business, and operational culture that is focused squarely on driving a distinct set of business outcomes. So, while it’s tempting to think about SaaS through the lens of technology patterns and strategies, you should really be viewing SaaS more as a business model.

To better understand this mindset, think about how adopting SaaS impacts the business of a SaaS provider. It directly influences and shapes how teams build, manage, operate, market, support, and sell their offerings. The principles of SaaS are ultimately woven into the culture of SaaS companies, blurring the line between the business and technology domains. With SaaS, the business strategy is focused on creating a service that can enable the business to react to current and emerging market needs without losing momentum or compromising growth.

Yes, features and functions are still important to SaaS companies. However, in a SaaS company, the features and functions are rarely introduced at the expense of agility and operational efficiency. When you’re offering a multi-tenant SaaS solution, the needs of the many should always outweigh the needs of the few. Gone are the days of chasing one-off opportunities that require dedicated, one-off support at the expense of long-term success of the service.

This shift in mindset influences almost every role in a SaaS company. The role of a product owner, for example, changes significantly. Product owners must expand their view and consider operational attributes as part of constructing their backlog. Onboarding experience, time to value, agility—these are all examples of items that must be on the radar of the product owner. They must prioritize and value these operational attributes that are essential to creating a successful SaaS business. Architects, engineers, and QA members are equally influenced by this shift. They must now think more about how the solution they’re designing, building, and testing will achieve the more dynamic needs of their service experience. How your SaaS offering is marketed, priced, sold, and supported also changes. This theme of new and overlapping responsibilities is common to most SaaS organizations.

So, the question is: what are the core principles that shape and guide the business model of SaaS companies? While there might be some debate about the answer to the question, there are some key themes that seem to drive SaaS business strategies. The following outlines these key SaaS business objectives:

Agility

This term is often overloaded in the software domain. At the same time, in the SaaS universe, it is often viewed as one of the core pillars and motivating factors of a SaaS business. So many organizations that are moving to SaaS are doing so because they’ve become operationally crippled by their current model. Adopting SaaS is about moving to a culture and mindset that puts emphasis on speed and efficiency. Releasing new versions, reacting to market dynamics, targeting new customer segments, changing pricing models—these are amongst a long list of benefits that companies expect to extract from adopting a SaaS model. How your service is designed, how it’s operated, and how it’s sold are all shaped by a desire to maximize agility. A multi-tenant offering that reduced costs without realizing agility would certainly miss the broader value proposition of SaaS.

Operational efficiency

SaaS, in many respects, is about scale. In a multi-tenant environment, we’re highly focused on continually growing our base of customers without requiring any specialized resources or teams to support the addition of these new customers. With SaaS, you’re essentially building an operational and technological footprint that can support continual and, ideally, rapid growth. Supporting this growth means investing in building an efficient operational footprint for your entire organization. I’ll often ask SaaS companies what would happen if 1,000 new customers signed up for their service tomorrow. Some would welcome this, and others cringe. This question often surfaces key questions about the operational efficiency of a SaaS company. It’s important to note that operational efficiency is also about reacting and responding to customer needs. How quickly new features are released, how fast customers onboard, how quickly issues are addressed—these are all part of the operational efficiency story. Every part of the organization may play a part in building out an operationally efficient offering.

Innovation

The ability to move faster has lots of benefits for SaaS organizations. It frees them up and lets them be more open to experimenting and shifting their strategy. The investments in agility and operational efficiency allow organizations to be much more fluid and flexible. This allows them to embrace new opportunities, new market segments, new packaging/pricing strategies, and a host of other possibilities. The overall goal is to use the underlying strengths of your operational and cost model as the fuel of your innovation engine. It’s this innovation that can play a big role in the broader success of your SaaS business.

Frictionless onboarding

SaaS businesses must give careful consideration to how customers get introduced into their environments. If you are trying to remain as agile and operationally efficient as possible, you must also think about how customer onboarding can be streamlined. For some SaaS businesses, this will be achieved through a classic sign-up page where customers can complete the onboarding process in an entirely self-service manner. In other environments, organizations may rely on an internal process to drive onboarding. The key is that every SaaS business must be focused on creating an onboarding experience that removes friction and enables agility and operational efficiency. For some, this will be straightforward. For others, it may take more effort to rethink how the team builds, operates, and automates its onboarding experience.

Growth

Every organization is about growth. However, SaaS organizations typically have a different notion of growth. They are investing in a model and an organizational footprint that is built to thrive on growth. Imagine building a highly efficient car factory that optimized and automated every step in the construction process. Then, imagine only asking it to produce two cars a day. Sort of pointless. With SaaS, we’re building out a business footprint that streamlines the entire process of acquiring, onboarding, supporting, and managing customers. A SaaS company makes this investment with the expectation that it will help support and fuel the growth machine that ultimately influences the margins and broader success of the business. So, when we talk about growth here, we’re talking about achieving a level of acceleration that couldn’t be achieved without the agility, operational efficiency, and innovation that‘s part of SaaS. How much growth you achieve is relative. For some, growth may be adding 100 new customers, and for others it could mean adding 50,000. While the nature of your scale may vary, the goal of being growth-focused is equally essential to all SaaS businesses.

The items outlined here represent some of the core SaaS business principles. These are concepts that should be driven from the top down in a SaaS company where the leadership places clear emphasis on driving a business strategy that is focused on creating growth through investment in agility, operational efficiency, and growth goals.

Almost every dimension of your SaaS architecture and strategy is going to be derived from your business vision. The target tenant personas, the packaging, the pricing, the cost model, and a host of other factors are going to shape the architecture, operations, and management footprint of the solution you ultimately build. If you don’t have clarity and alignment with the business around these points, you’re unlikely to be in a position to build a SaaS offering that fully realizes your business goals.

Building a Service—Not a Product

Many software providers would view themselves as being in the business of creating products. And, in many respects, this aligns well with their business model. The mindset here is focused on a pattern where we build something, the customer acquires it, and it’s, for the most part, theirs to use. There are plenty of permutations and nuances within this product-centric model, but they all gravitate toward a model that is focused on creating something more static and having customers buy it.

In this product-focused mindset, the emphasis is generally on defining the features and functions that will allow a software provider to close gaps and land new opportunities. Now, with SaaS, we shift from creating a product to creating a service. So, is this just terminology, or does it have a meaningful impact on how we approach building a SaaS offering? It turns out this is certainly more than a terminology shift.

When you offer software as a service, you think differently about what success looks like. Yes, your solution needs to meet the functional needs of your customers. That dimension of the problem doesn’t go away. As a service, though, you are much more focused on the broader customer experience across all dimensions of your business.

Let’s look at an example that better highlights the differences between a service and a product. A restaurant provides a good backdrop for exploring these differences. When you go out to dinner, you’re certainly looking forward to the food (the product). However, the service is also a part of your experience. How fast you’re greeted at the door, how soon the waiter comes to your table, how soon you get water, and how quickly your food arrives are all measures of your service experience. No matter how good the food is, your quality of service will have a lot to do with your overall impression of the restaurant.

Now, think about this through the lens of a SaaS offering. Your SaaS tenants will have similar service expectations. How easily they can onboard your solution, how long it takes to realize value, how quickly new features are released, how easily they can provide feedback, how frequently the system is down—these are all dimensions of a service that must be front and center for SaaS teams. Having a great product won’t matter if the overall experience for customers does not meet their expectations.

This takes on extra meaning when software is delivered in a SaaS model, where the tenant’s only view of your system is the surface of your SaaS solution. SaaS tenants have no visibility into the underlying elements of your system. They don’t think about patches, updates, and infrastructure configuration. They only care that the service is providing an experience that lets them maximize the value of your solution.

In this service model, we also often see SaaS companies leveraging their operational agility to drive greater customer loyalty. These SaaS providers will get into a mode where they release new capabilities, respond to feedback, and morph their systems at a rapid pace. Seeing this constant and rapid innovation gives customers confidence that they will be benefactors of this constant evolution. In fact, this is often the tool that allows emerging SaaS companies to take business away from traditional non-SaaS market leaders. While some massive, established market leaders may have a much deeper feature set, their inability to rapidly react to market and customer needs can steer customers to nimbler SaaS-based offerings.

So, while this product versus service comparison may seem a bit pedantic, I view it as an essential part of the SaaS mental model. It connects directly to this idea that SaaS is very much a mindset that shapes how entire SaaS organizations approach their jobs and their customers. In fact, many SaaS organizations will adopt a series of metrics that measure their ability to meet their service-centric goals. It may be tempting to view this as something that can be bolted onto your service at some future date. However, many successful SaaS organizations rely on these metrics as a key pillar of their SaaS business.

The B2B and B2C SaaS Story

As teams talk about SaaS, they’ll often map strategies and patterns to the business-to-consumer (B2C) and business-to-business (B2B) models. As I discussed in the preface, it’s important to understand that there are clear differences in how you might approach architecting for these two models. The scale of B2C, for example, will often require highly specialized strategies that can accommodate the workload profile and cost models of these environments. At the same time, at the conceptual level, lots of topics and mechanisms discussed here could apply to B2C and BCB environments. I won’t try to highlight every instance where these models might require different approaches. There are too many variables here to make absolute statements about what fits for B2C and what fits for B2B. So, for the scope of this book, let’s acknowledge that being B2C or B2B can certainly influence the overall architectural model of your solution.

Defining SaaS

I’ve devoted the bulk of this chapter to bringing more clarity to the boundaries, scope, and nature of what it means to be SaaS. It only seems fair to take all the information we discussed here and attempt to provide an explicit definition of SaaS that, ideally, incorporates the concepts and principles that we have covered. This is the definition I think best summarizes the view of SaaS I’ll be using across the rest of this book:

SaaS is a business and software delivery model that enables organizations to offer their solutions in a low-friction, service-centric model that maximizes value for customers and providers. It relies on agility and operational efficiency as pillars of a business strategy that promotes growth, reach, and innovation.

You’ll see that this definition sticks to the theme of SaaS being a business model. There’s no mention of any technologies or architecture considerations. It’s your job as a SaaS architect and builder to create the underlying patterns and strategies that enable the business to realize its objectives. While that may seem like the job of any architect, it should be clear that the unique blend of business and technology demands for SaaS environments will be infused directly into the design, architecture, and implementation of your SaaS solution.

Conclusion

This chapter was all about establishing the foundational elements of the SaaS mindset, providing you with a core set of concepts and terms that will be critical as we dig deeper into SaaS architecture patterns and strategies. A key part of our discussion was focused on understanding the fundamental goals of SaaS, highlighting the key elements that have motivated so many organizations to adopt a SaaS delivery model. This required us to look more closely at classic software delivery models, highlighting some of the traditional challenges associated with these models. Then, I shifted to exploring how SaaS is used to overcome these challenges, delivering efficiencies, economies of scale, and agility that can enable greater levels of growth and innovation. A key point is that SaaS architects and builders can’t just be focused on creating a solid SaaS application—they must also be thinking about how their solution will solve the organization’s broader operational, agility, and efficiency goals.

A big part of this chapter was also focused on aligning on some core concepts. I introduced the idea of tenants, highlighting some of the key nuances with building environments where infrastructure can be consumed in a shared model. Our discussion on shared infrastructure also highlighted some of the key differences between SaaS and traditional installed, per-customer models. At the core of this theme was the idea of creating a unified experience that would enable you to collectively manage, deploy, and operate your SaaS tenants.

It was also essential to create clearer boundaries around what’s SaaS and what’s not (at least for the scope of this book). It’s here that I started looking at multi-tenancy and the historical baggage that’s attached to this term. The goal was to create a new SaaS-aware view of multi-tenancy that moved away from the narrow, infrastructure-centric idea of multi-tenancy. I reviewed a series of SaaS deployment strategies to highlight the need for a broader definition of multi-tenancy that wasn’t connected to whether we were sharing infrastructure. Having clarity around when and how the multi-tenant term is used is fundamental to how we talk about SaaS and how we describe SaaS architectures.

Finally, toward the back of the chapter, I started trying to further refine the boundaries of SaaS. I looked at the MSP model, for example, and reviewed some of the key factors that separate the MSP and SaaS models. I also looked at some of the core principles that I thought should be applied when shaping the vision for building a SaaS organization and offering. This included reviewing some of the key differences that are associated with building a service (instead of a product).

The hope is that this chapter equipped you with a better sense of how we’ll be viewing SaaS throughout this book. Alignment on these principles will allow us to move through additional, more concrete concepts with a common view of what forces are shaping and guiding our architectural choices. Ideally, it also removes some of the confusion that, historically, has surrounded this topic.

Now that we have these SaaS mindset basics in place, we can start thinking about how these principles are mapped to more specific architectural patterns and constructs. In the next chapter, I’ll make an end-to-end pass through all of the key SaaS architecture mechanisms and strategies without bringing in the specifics of any one solution or technology stack. This will expose a full range of the considerations that should be part of defining any SaaS architecture. Defining tenant context, discussing what common services and capabilities we need, explaining data partitioning—these are all on a much longer list of more detailed insights that we’ll be covering. The goal of this chapter is to review many of the higher-level SaaS architecture constructs, explaining their role, their nuances, and where they fit into the overall SaaS architecture landscape.