Notes from Anywhere by Nelson Nones

The Inside Story of GeoBooks On Demand (Part 4)

In previous posts, I've discussed:

• The vision for GeoBooks On Demand ERP Software as a Service (Part 1) -- enabling our customers to harmonize their global operations cost-effectively by delivering ERP as a service that works in multiple locations, time zones, languages and currencies, and is available and accessible from anywhere on Earth.
• GeoBooks Exclusive Service architecture (Part 2), which gives customers the option to keep total control over their business data by hosting their own database, without having to license or install any ERP software on their own premises.
• Multi-tenant architecture for the GeoBooks Virtual Private Database (VPD) Service (Part 3), which makes makes it simple for Geoprise and our customers to set up and manage GeoBooks On Demand subscriptions, while providing secure separation of customer data.

Let's turn next to the architecture for multiple languages.

Lots of software makers claim to "support multiple languages," but what this really means is that the standard user interface (menus, screens, report layouts, documentation) is available in two or more languages. Enabling a single application host to display the user interface in any language requires software makers to implement a standard known as Unicode, which wasn't introduced until 1991. Many of the ERP applications in use today were originally designed in the 1980s, however. Re-engineering them to take advantage of Unicode can be a monstrously complex undertaking (I know this from painful experience; I was in charge of 2 such projects for major software vendors earlier in my career).

Along with Unicode came a body of best practices for software internationalization (i18n, for short). According to Wikipedia's article on Internationalization and localization, "Internationalization is the adaptation of products for potential use virtually everywhere, while localization is the addition of special features for use in a specific locale. The processes are complementary, and must be combined to lead to the objective of a system that works globally." In practice, for displaying text in local languages and writing systems, the text shown by an application's user interface should be separated from the application's program logic rather than embedded within it. This makes it much easier to introduce the user interface in a new language, because all you have to do is translate the text. If the application is already internationalized, there's no need to re-write any program logic or recompile the application.

But, again, re-engineering ERP applications that were originally designed in the 1980s so they are fully internationalized is a major technical challenge.

Happily, Geoprise was able to avoid both challenges because we designed and built GeoBooks On Demand as a fully-internationalized application from the very beginning, deploying the Unicode standard throughout. Today, GeoBooks On Demand is available in standard English and we have begun to translate the user interface into Thai. Additional translations into Bangla, Chinese and Mexican Spanish are also in the works. In true Web 2.0 fashion, we allow our customers to contribute their own translations of the user interface into any of 145 additional languages through the GeoBooks On Demand Community Home site.

System Administrators choose each user's default language preference when adding new users to their GeoBooks On Demand subscription. The GeoBooks On Demand user interface is shown in each user's default language when the user logs on. Users can also change their language after logging on.

So, in short, GeoBooks On Demand meets or beats any software maker's claim to support multiple languages. But that's only half the story.

Traditional ERP applications provide descriptions for database objects; for example, the company name in the company master. This is not adequate, however, when the company name must be presented in multiple languages. Geoprise Technologies, for example, has corporate entities in both the United States and in Thailand. The English name for our Thai entity is “Geoprise Technologies Co., Ltd.” while the Thai name for the same entity is “บริษัท  จีอไพร์ส เทคโนโลยี  จำกัด”. Moreover, it is a legal requirement to show the Thai-language name on certain business documents such as financial statements.

Postal addresses are somewhat more complex. Instead of a single description, an address could have several lines or could be parsed into the street name, city name and so forth. When sending something to a foreign address, one must assume that postal clerks in the foreign country cannot understand an address that is written in the language of the origin country, nor can people in the origin country understand an address that is written in the language of the destination country. In this situation, it would be best to maintain the address details in two languages rather than one.

GeoBooks On Demand solves this problem by allowing descriptive text for each database object to be maintained in any language. No other ERP application on the market today (this includes on-premise as well as on-demand offerings) can make this claim.

This feature is not only unique, it is easy to use as well. For example, when a user adds a new company, GeoBooks On Demand requires the company name to be entered in the user's current language -- just like a conventional ERP application that provides only one company name. Likewise, GeoBooks On Demand will display company names in the user's current language on all screens and reports. When maintaining the company master, on the other hand, users can maintain company names in any language without having to switch their current language. You can see examples of this in the Geoprise Web site.

As a result, we think that GeoBooks On Demand takes the meaning of multiple language support to a whole new level.

The Inside Story of GeoBooks On Demand (Part 3)

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.