6974013-SaaS-Architecture (1)

8/7/2019 6974013-SaaS-Architecture (1)

1/13


2/13

Changing the Business Model Changing the business model could involve one or more of the

following: Shifting the "ownership" of the software from the customer to an

external provider. Reallocating responsibility for the technology infrastructure and

managementthat is, hardware and professional servicesfromthe customer to the provider.

Reducing the cost of providing software services, throughspecialization and economy of scale.

Targeting the "long tail" of smaller businesses, by reducing theminimum cost at which software can be sold.


3/13

From an application architect's point of view, there are three key differentiators

that separate a well-designed SaaSapplication from a poorly designed one. Awell-designed SaaS application isscalable , multi-tenant-efficient , andconfigurable .


4/13


5/13

1

traditional clientserver applications canbe moved to a SaaS model at the firstlevel of maturity, with relatively littledevelopment effort, and without re-architecting the entire system from theground up. Although this level offers few of the benefits of a fully mature SaaSsolution, it does allow vendors to reducecosts by consolidating server hardwareand administration.


6/13

2

repositioning a traditional application asSaaS at the second maturity level can

require significantly more re-architectingthan at the first level, if the application hasbeen designed for individual customizationrather than configuration metadata.


7/13

3

This approach eliminates the need to provide server space for as many instances as the vendor hascustomers, allowing for much more efficient use of computing resources than the second level, whichtranslates directly to lower costs. A significantdisadvantage of this approach is that the scalability of the application is limited. Unless partitioning is used tomanage database performance, the application can bescaled only by moving it to a more powerful server

(scaling up), until diminishing returns make it impossibleto add more power cost-effectively.


8/13

4

At the fourth and final level of maturity, the vendor hostsmultiple customers on a load-balanced farm of identicalinstances, with each customer's data kept separate, andwith configurable metadata providing a unique user experience and feature set for each customer. A SaaSsystem is scalable to an arbitrarily large number of customers, because the number of servers andinstances on the back end can be increased or decreased as necessary to match demand, without

requiring additional re-architecting of the application, andchanges or fixes can be rolled out to thousands of tenants as easily as a single tenant.


9/13

Choosing a Maturity Level

What maturity level should you target for your application? One mightexpect the fourth level to be the ultimate goal for any SaaS application, butthis isn't always the case. It may be more helpful to think of SaaS maturityas a continuum between isolated data and code on one end, and shared data and code on the other


10/13

H igh-Level Architecture

Architecturally, SaaS applications are largelysimilar to other applications built using service-oriented design principles

The most significant difference is the addition of metadata services, which are responsible for managing application configuration for individualtenants. Services and smart clients interact withthe metadata services in order to retrieveinformation that describes configurations andextensions that are specific to each tenant.


11/13


12/13

Metadata ServicesIn a mature SaaS application, the metadata service provides customers with the primary means

ofcustomizing and configuring the application to meet their needs. Typically, customers can makeconfiguration changes in four broad areas:User interface and branding Customers often appreciate the ability to modify the user interfaceto reflect their corporate branding, and therefore SaaS applications typically offer features thatallow customers to change things such as graphics, colors, fonts, and so on.Workflow and business rules To be of use to a wide range of potential customers, a business-critical SaaS application has to be able to accommodate differences in workflow. For example,one customer of an invoice tracking application may require each invoice to be approved by amanager; a second customer may require each invoice to be approved by two managers insequence; a third may require two managers to approve each invoice, but allow them to work inparallel. When appropriate, customers should be able to configure the way in which theapplication's workflow aligns with their business processes.Extensions to the data model For many data-driven SaaS applications, one size definitelydoesn't fit all. Even with relatively simple, task-specific applications, customers may chafe under the restrictions imposed by a static, unchanging set of data fields and tables. An extensible datamodel gives customers the freedom to make an application work their way, instead of forcing them

to work its way. Later in this paper, you'll learn a bit more about how a customer-extensible datamodel is architected.Access control Typically, each customer is responsible for creating individual accounts for endusers, and for determining which resources and functions each user should be allowed to access.Access rights and restrictions for each user are tracked by using security policies, which shouldbe configurable by each tenant.


13/13

6974013-SaaS-Architecture (1)

Documents