More on Scalability - At the Application Level

A few weeks ago I posted on scalability, in particular high level systems and software scalability (please refer to this previous post if you don't understand some of the terms in this post). I want now to briefly touch on a business's ability to scale geographically and how this applies to software applications. This post therefore contains a few more areas to use as part of evaluating potential software vendors. Also, as before it is generally about internet gambling products.

One way a business can scale up is to take its products and services from one market and sell them in a different market. It is important that if this type of activity is part of the business strategy, the business's applications that make up its products and services will faciliate this expansion.
When Internet games/gambling businesses expand in this way, they tend to get caught out in three primary areas:

• Language translation
  
• Localization and usability
• Currency

1. Language translation

For web pages and from a customer facing perspective, language should be a simple matter to change. This process is often called localization, although it should be called translation. Providing there is good separation between presentation and logic, it's typically easy to break down all the text into chunks, translate each chunk, then re-forumulate the pages.

Some languages present unique challenges such as right to left and top to bottom reading - that will be covered under Localization and usability.

This is typically more difficult for a heavy client as the text is sometimes more difficult to get at and change, and there is a heavier process for testing and distributing the resultant new heavy client. Again, providing a solid process was used to maintain text catalogs in the client, this should be fairly straightforward.
This is somewhat obvious, but on both the customer facing side AND the back office side, you should be able to effortlessly switch languages. While this isn't so important for customers, it is invaluable from a backoffice and testing side.

There are several gotchas I've encountered when discussing localization with a vendor. First, they may claim to have "localized", but all they've really done is translate the customer-visible test. Second, error messages, often generate at the applications layer, are missed by the translation effort. Third, translations haven't been done end-to-end such that the backoffice has had all text fully translated as well. All of three of these areas are required for a product to even start to be considered "localized".
Therefore, another way to measure product scalability is how quickly the product can be translated, end-to-end (customer facing to back office).
A subtlty in this area is not just what customers and employees see, but also how they enter data. For example, when a customer enters their stake for a football bet, are you ready to accept numbers both in Western Arabic form (1, 2, 3, ...) and Chinese form ( 一, 二, 三)?
Lastly, in the area translation, you may want to be able to set, easily change, and translate to/from your primary back office language. For example, to save money you may decide your Thai customer support team doesn't need to be bi-lingual. This means that all your customer facing and backoffice system must be in Thai. However, the common corporate language may be English, and all the customer service KPI results must be viewable in English and Thai.

2. Localization and usability
Localization is really much more than just translating text. It is about refactoring your product or service so that it is usable by your target market.
As a first pass on the road to localization, a business will often translate and offer one or more new languages.
The next step is to conduct usability studies to verify that your translations make contextual sense. This will often result in substantially different application UI ("User Interface", e.g., web page) layout changes, different types of help offerings, brand/color changes, and changed emphasize of product features.
Scalability in this area primarily means that the products UI allows for quick and simple changes to how information is presented to your customers and staff. Are the web pages made up of components that can be shuffled about easily? Do the web pages allow for global style changes to be made?
3. Currency
There are many aspects of handling financial accounts in gambling systems. Limiting this post to scalability, a financial system is scalable if it provides the following major features:

• Does the system support any number of different currencies?
• Can a customer select their working currency of choice, that is, the currency used to display all monetary figures to that customer?
  
• Can each discrete customer have multiple financial accounts (e.g., a credit card in USD, a bank account in GBP, and a Neteller account in EUR) each in multiple different currencies?
• Can the system accept and calculate against any number of currency conversion values on a frequent (at least daily) basis?
• Can the system have any number of financial accounts to represent internal operations
• Can the system easily switch between any number of currencies for back office reporting?
  

On the last point, a business will typically select its internal operating currency on a corporate level and work to it. However, for ad-hoc reporting, it is quite convenient to be able to easily switch between currencies for reporting.
---
The above areas are three more points you can use when evaluating gambling platform software vendors, at least if you're interested in adding a second language or currency.