Having worked out an architecture that gives customers the option of hosting their own database (Part 2), I next turned to the multi-tenant architecture needed by customers who choose the centrally-hosted database. Unlike traditional software which is built and distributed on the principle that each customer runs a separate instance of the application and its underlying databases, GeoBooks On Demand is deployed as a single instance that is hosted by my company, Geoprise, and offered on a subscription basis. Each subscription is managed as a separate hosting account. Such deployment requires a means for securely separating the data belonging to each subscriber so that it is impossible for the other subscribers to access or modify it.
Wikipedia contains an interesting article on Software as a Service (SaaS) that discusses the differences between ASP (application service providers) and SaaS. According to this article, "Early SaaS approaches were application service providers (ASPs) who ran a turnkey application on behalf of their clients. But ASPs generally did not build the application themselves; rather, they took an off-the-shelf application (such as a messaging platform, an enterprise resource planning tool, or a customer relationship management package) and ran it for customers. SaaS vendors typically use a multi-tenant architecture, meaning that multiple customers are running the same software, but with ... virtually separate data. ASPs by comparison, merely deployed one application instance on a server for each customer, just as a customer would deploy internally. This inability to scale this kind of business model may be cited as one of the reasons for the failure of the ASP model. It's reasonable to assume that multi-tenant architecture simplifies application management for the vendor. The multi-tenant model also simplifies the value for all customers since upgrades are instantaneous available across the entire platform."
I ultimately chose the Virtual Private Database (VPD) approach for our multi-tenant database. VPD architecture originated with U.S. Department of Defense (DoD) security requirements for separation of data by sensitivity level (SECRET, CONFIDENTIAL, UNCLASSIFIED) and implements row-level security (RLS) that is transparent yet cannot be subverted. Even though, in reality, Geooprise customers share the same GeoBooks On Demand instance, each of them appears to run their own instance and is never aware that other customers are using the same instance.
The VPD approach makes it very easy for Geoprise and its customers to set up and manage their GeoBooks On Demand subscriptions. On our side, all we have to to is add each new customer and their System Administrator's account to the existing GeoBooks On Demand database. There is no additional software to install or manage on our side, and of course no ERP software to install or manage on the customer's side, either (after all, it's SaaS). Next, the customer's System Administrator logs on and adds their users, assigning each user to a role such as Accounting Clerk or Controller. Each role is pre-configured to provide role-based access control and workflows which I will discuss in future articles. Also, the System Administrator has the option of tailoring their organization's preferences in each language they intend to use (I'll discuss GeoBooks On Demand multi-language features in a future article as well).
That's it!
VPD architecture also allows us to create a "shared" database partition containing information that all subscribers are likely to need and use. Countries and currencies are good examples. Why should each subscriber have to set up and maintain their own country and currency lists? So, the GeoBooks On Demand database contains dozens of "seed" data categories that allow our customers to get off to a quick start. The seed data is available not only for customers who use the centrally-hosted database, but also to customers who host their own database.
Comments