Before you shout “Digital Transformation” in a crowded marketplace, it’s important to recognize two foundational principles in developing a SaaS product plan.

  • First: SaaS is a business strategy, not a technology strategy.
  • Second (a corollary of the first): There is no one-size-fits-all SaaS architecture.

That makes for a vast landscape of pitfalls in the search for common ground between business and architecture. Success in spite of these obstacles? There are at least three foundational dimensions that translate your business assumptions into critical technical solution inputs:

  • User Model
  • Monetization
  • Measurement

In this blog series, we explore how these three dimensions figure into key technical recommendations which enable scale in pursuit of SaaS business growth.

Part 1: User Model & Onboarding

If you have a business model, you have put together ideas about users. Some of them are the people who pay for your system; some of them are users who other people pay for. So let’s define a user model as the collection of characteristics, capabilities, and activities of all the users of your SaaS application. Put another way, the user model describes the “who” of what your software does.

So what’s special about how your User Model helps drive a better design of the SaaS? The simplifying power of the MVC software design pattern makes it tempting to assume that SaaS and web application development is no more than a web-based version of a 3-tier stack. True, laying out UI/UX front-end logic backed by a database, relational or otherwise, makes for quick prototyping and proof of concept. Yet we’ve often seen investors and early pilot users lose sight of the limits of the brainstorming phase and low-fidelity prototyping, and in some cases, dive right into slick UI/UX.

To be ready for growth, SaaS needs to take the questions of a user model to the next level. What was once thought of as the “back end” requires a good hard look at the system as a whole. This means that every user, and every user’s role, has to be specified more precisely for every customer. (see “Who does what, where and when” below. ) Let’s do that by viewing that next level through the lens of onboarding.

Onboarding in SaaS is an end-to-end process.

  • Sign-Up is the most recognizable part of onboarding, as it’s where the application captures information about who is going to use the software and how the subscription gets billed.
  • From a technical platform perspective, onboarding provides the anchor for operationalizing all aspects of your user model and customer operations.
  • User- and customer-specific application logic and data services are provisioned in a way that enables streamlined monitoring and updating

In SaaS terms, this combination of user and customer is called tenant context. Onboarding operationalizes your user model by expressing it through tenant context. In other words, tenant context defines the moving parts of your saas application.

Technical side note: the emergence of microservices has enabled a very rich set of possibilities of SaaS business models and configurations of users. We won’t get into it here (just one of many examples) around permutations to specify, trade-offs between containers and Kubernetes, and on and on. For a deep dive, have a look at the AWS Definitions – SaaS Lens; for a deeper dive, see the Google DevOps Catalog here. Or just drop us a line.

Who does what, where and when

Let’s examine this user model perspective of the “who does what” in your SaaS application in more detail.

Tenant identity is the unique, traceable, and secure mechanism for distinguishing tenants from one another. The attributes of the tenant identity mechanism are generated at onboarding via the use of JSON Web Tokens (JWT). This encryptable data structure reliably flows SaaS identity and activity scope into each application service and data structure. The function of “Who does what, where and when” is foundational to SaaS monetization and measurement.

Multi-tenancy structures the allocation of the resources for each specific tenant. It also sets up explicit rights and privileges which that tenant is entitled to.

  • One of the most basic ways to ask the question is whether your SaaS has a large number of small customers or a small number of large customers.
  • An essential part of the onboarding process is provisioning and deploying those resources like compute, network, storage, and the gamut of higher-level service functions required by your user model. How much should each get? (a Slack account is a good example where your company is a tenant and there are users within it with different rights and privileges.)
  • The Goldilocks method is a good first approximation: for each level in your user model (aka ‘tier’), not too much and not too little.

Designing the architecture following your user model is essential to ensuring multi-tenancy translates into services that can be duplicated, automated, leveraged and reused.

Tenant Isolation takes the benefits of duplication afforded by your user model and ensures that infrastructure boundaries are enforced in line with tenant context. There are many ways in which this applies.

  • It ranges from data and resource access security and compliance all the way to ensure that Goldilocks rules for different tenants don’t inadvertently chomp up each other’s resources (in a distributed virtual environment, this is known as the “Noisy Neighbor” problem).
  • In some cases, tenant isolation requirements mean that there are resources that must not be shared. This can be a tricky balance: some customers will pay extra to have resources that no one else can see or touch.
  • Tenant isolation also drives requirements for security, compliance, geo-based platform selection, data privacy, and more. For instance, HIPAA compliance requires a very different user model than multiplayer social games.

Tenant isolation is a balancing act.

  • Resource isolation as an expression of tenant isolation also creates the temptation to code up custom branches to the user model.  
  • Custom branches which then degenerates into only part of your application functioning as SaaS and fragments your user model (not to mention monetization, coming up in the next section).

Operationalizing the user model

Understanding your user model through the lens of onboarding also raises important questions in planning the operating model for your SaaS.

  • How frequently do you expect to add new customers and users?
  • Is it often enough to merit zero-touch deployment automation, with clear policies for who gets how much of which resources? (highly desirable)
  • Do you need to create a trial version with limited capabilities (and limited platform resources) to persuade your customers to use your application?
  • What constitutes success for a user or a customer in a discrete and quantifiable outcome?

It’s worth noting that it can be challenging to choose exactly which features are offered to which customers at which point in your product development life cycle. When you have a small number of large customers, they can have an outsize influence on the choices you make in your feature roadmap.

Our strongly held opinion is that business strategy comes before the key design decisions that comprise a SaaS platform technical architecture. (We’ve learned the hard way that reversing the sequence is not the best approach.) More specifically, committing upfront to data models, provisioning automation, and even user onboarding can make it more expensive to pivot down the road.

The more we understand about your user model, the better we can recommend which architectural options best support your business strategy.

Aligning your SaaS business strategy with SaaS technical architecture is critical to SaaS success. See more about all 3 M’s in these two companion blog posts Part 2: Monetization and Part 3: Measurement. For a thorough assessment of options for a SaaS business model, download the AWS SaaS Journey Framework whitepaper, and/or take a technical deep dive into the SaaS Lens for the AWS Well-Architected Framework.