 |
|
|
|
|
Being software developers of similar products and implementing variations on the same standard (SQL), it would be expected that each vendor would have a common set of problems to overcome if they were to implement Unicode. Upon investigation, and interviewing various program and product managers in as many of the companies as possible, it was found that this was, indeed, the case.
Each vendor garners a portion of their revenue from a mix of new customers, maintenance contracts, consulting, and license renewals or upgrades. This latter category is usually protected with religious fervour because it is the bread and butter for future generations of the product. If a customer has a difficult upgrade process, or must bring a whole system down for an extended period of time to convert data from one encoding to another, the incentive to stay with that particular vendor decreases dramatically. Some of the databases handle mission-critical information ranging in size from a few gigabytes to multiple terabytes. A customer with a large database would consider it absolutely unacceptable to be required to reconfigure or convert all their data to be able to use the next version of a product.
Sometimes management must be educated as to why Unicode is a viable or necessary enhancement to existing architectures [30]. Often-times, management may need education about the basic issues of internationalisation before progress can be made. A proper education as to the market issues and increased market share that can be obtained with a properly globalized and portable product is useful as well.Constant I18N education of developers is important too. Engineering must be educated about the nuances of the Unicode standard, and be made aware of what tools exist for developing Unicode-aware or Unicode-enabled products (hence this conference :-).
A company may be strapped for budgets, and so cannot hire the full compliment of designers that they desire. When budgets are released and it comes time to building an international team to implement the robust language features that usually go along with Unicode, managers become painfully aware of how hard it is to find engineers that are technically adept and cross-culturally savvy. It takes on average six months to fill a position for an Internationalisation Engineer. Longer if an engineer with specific database internals experience is desired.When a release is going through its product cycles, other "features" may compete for space on the short-list of included functionality, possibly postponing Unicode until a later release.
When Unicode development is underway, it must be co-ordinated with existing release schedules, dependent products, testing, packaging, documentation, and training.
Luckily, it seems that most of the above issues are being resolved with respect to the major database vendors. It appears that almost all of themare actively involved in offering or developing Unicode solutions for the marketplace.
|
|
|
|