Is the Tokyo Node Being Left Behind?

Japanese branches and subsidiaries of global corporations face special problems in this era of downsizing and integration. In this month's Viewpoint, application developer Todd Boyle offers a pessimistic vision of the future.

WITH ALL OF THE EPOCHAL CHANGES IN COMPUTERS--

• downsizing: companies moving to client/server,
• integuation: of enterprise systems with the desktop, and
• communications advances: global e-mail, groupware, and connectivity to the Internet universe--

Are Tokyo IT managers and their host businesses destined to be left behind! The most likely answer is: YES!

The effects of downsizing Client/server nodes spread across international networks, for most global companies, are out of the question given current communication costs. The essential element of client/server, after all, is shared reference tables: cus tomer lists, accounts, product codes, etc. Without these, you can't create valid transactions. So, an office in Japan would need to be able to read the global reference tables in each other country, and to be able to change them: adding a customer, deleti ng a product code, etc. And every office in the world needs to be kept current on the changes; otherwise, there will be piles of invalid transactions in no time!

The basic mainframe and UNIX solution was to put dumb terminals in all the offices and hard-wire them all to the mainframe data, e.g., with leased lines. That's one way to be sure, but leased lines are too expensive for 99% of those who need to access the system. This method is too slow besides, because the whole burden of computing is focused on the centralized system.

The simplest client/ server solution isn't a whole lot different from terminal-host, especially for a single location: PC's are logged into a single, main database server. The PC runs beautiful interfaces and intelligent application programs, but the "login session" and the data remain in the same place they always did: inside a minicomputer or mainframe. There are lots of advantages to this setup--but if you're in Japan and your data resides on another continent 6,000 miles away, cheapness is certain ly not among them!

More realistically, your company could run a full-blown RDBMS here in Japan, one supporting most of the "local" automation requirements while being simultaneously connected to the home country RDBMS for "global" transactions. For example, say your com pany sells engines, and that while the master copy of the ledger is in New York, the inventory system is in Japan. If you sell an engine to a customer, both the New York ledger and the local inventory must be updated. This is called "distributed data" bec ause you have master files in more than one location.

In order to maintain a high degree of integrity, either all of the locations must accept the whole transaction pretty much simultaneously, or none of them may accept it. Oracle calls this mechanism "Two-Phase Commit." There is a "prepare to commit" st age on all the affected database servers (to see if it passes all the tests) and then the "final commit." Twophase commits are a marvelous achievement, but they are so complicated that communications costs and delavs render them generally out of the quest ion in the 1990s between Japan, the US, and Europe.

ORACLE databases are hyper-conservative, even running on a single machine: every transaction is written in at least three places. The changes are written into database and redo log files (for rebuilding the entire database in case the database disk di es), and pre-images are written to rollback segments (in case the commit fails, or the session fails, etc.). Pointers are also updated in multiple copies of the control files. Then you've got the indexes and zillions of other tables, for everything from s ecurity to data constraints.

So, Sally hits "Enter," and blizzards of data fly across the wire! Disks churn! Picture a two-phase commit for every invoice back to the main site in New York, with the whole thing held open until two database servers agree it's OK to post, and postin g dozens of files each time. Now picture this against normalized tables, with hundreds of tables held open and with a full-time, uninterrupted connection by leased line. Throw in a few more sites with replicates of the tables-you have to wait for all of t hose to be updated, and...

Well, it ain't going to happen for the Japan node. At least not in the 1990s.

So what is the alternative? The currently fashionable idea is to maintain copies of the reference tables in all offices. The RDBMS vendors advertise products that will take on the burden of keeping the tables in sync, automatically. How wonderful, you may think! This relieves the programmers and engineers of so many headaches!

But, this is so complicated that very few vendors can really keep the multiple copies in sync: mainly Oracle and Sybase.

Sybase's bid is called "Replicated Servers," and Oracle does basically the same thing with its "Snapshots" feature. The tables on database servers in different locations are allowed to go out of sync for defined periods, but there is a complicated sch eme to bring each RDBMS back "in-sync." This approach lets you enter transactions fast, without waiting for responses from the master database, and it's cheaper because you aren't continuously connected. But there are tradeoffs: the data isn't as accurate , and it isn't exactly cheap. And when you log into New York to get your database updated, watch out! Every change, originating anyplace in the world since the last time you updated, will be sent to you.

Integration of enterprise systems with the desktop

Building integrated systems is as intensely interpersonal and political an undertaking as could possibly be. You have to re-engineer the workflow! This requires face-to-face meetings with users, intimate understanding of the relationship with customers , coordination with fellow systems people locally and remotely, and an ability to communicate with the "over-60" bunch who make decisions but know almost nothing about the exercise.

The integration aspect provides two more reasons Tokyo IT managers will be left out in the cold:

1. The Tokyo node is unlikely to be included in most companies' plans to integrate the desktop work processes with the corporate database. Many foreign branches and subsidiaries in Tokyo are now running in the red, we're 10 hours out of phase wit h the East Coast or London, and we aren't material enough in size. In addition, Tokyo expats are often a bunch of mavericks who aren't well-connected politically in their home country, and they frequently don't understand their own Japanese process ing needs. Final ly, the systems in Japan are too spe cialized-and they ain't busted and don't need fixin' anyway!

2. The real power of enterprise applica tions is intimately connected with communications. Even if we were only 50 feet from the action and our work processes were identical, our node would be left out if it were in a domicile with communications costs comparable to those for Japan. The cost-benefit curve is constantly moving downward as equipment and software improve. It differs for every company, but there is a systemic prob lem: the green light for building client/ server solutions will f lash in the US sev eral years sooner than in Japan. And during those years, the client/server archi tecture will be designed without a Japan node.

Todd Boyle is a CPA and applications developer. He has been working in Japan since 1983.