NT’s Distributed Architecture

What would you do? You need to provide realtime access to 4000 clients, running OnLine Transaction Processing (OLTP) applications and batch jobs against 100 databases. The solution to this problem, at Brigham and Women's Hospital in Boston, Massachusetts, will surprise you--and it might just give you some ideas.

This hospital uses the Massachusetts General Hospital Utility Multi-Programming System (MUMPS) programming language to write applications. MUMPS is a language specifically for health-care data processing needs, and performs well. Because each MUMPS database is inherently distributed, the applications don't care where the data resides.

Brigham and Women's used to run MUMPS on midrange computers, but their limited architecture forced hospital staff to find a solution that offered room to grow. The approach they took was not the obvious one.

Instead of installing a large mainframe, the hospital looked for a PC-based solution and found InterSystems, an international provider of database management systems (DBMSs) and related software. InterSystems installed its product, Open M, on PCs to run the hospital's thousands of lines of indispensable MUMPS code. Open M is a combination of a DBMS and an application development environment based on the ANSI standard M language. The latest version uses Windows 95 and Windows NT and supports standard development tools such as Visual Basic (VB) to develop front-end, client applications.

If a set of midrange computers couldn't handle the hospital's needs, how can PCs do it? Here's where the distributed nature of a MUMPS database comes in. PCs don't lack power--they lack bandwidth. InterSystems increased bandwidth by distributing the computing across several PCs, creating a cheaper, more scaleable environment that performed as well as the old systems.

The InterSystems design consisted of PCs running--amazingly enough--DOS. Database servers on the back end provided access to the hospital's enterprise database. DOS client boxes on the front end ran MUMPS programs that accessed the servers, as needed. And data switches provided access at the data level, moving data from the servers to the clients. These switches were necessary because the limitations of DOS didn't allow enough connections to the database servers to handle all the requests.

The hospital liked this architecture because it made growth simple. As Jim Marra, corporate director of technology planning for Partners HealthCare Systems, explained: "When I need a new database server, I just go buy a 486 from anyone who has a good price."

Reliability was also a key factor. "Originally, we intended to provide automatic switchover in case one machine failed, but we never implemented it because it never became necessary," Marra said.

Saving lives and collecting money both require excellent system availability. Open M fills this requirement by providing subsecond response times for OLTP applications. As a rule in application design, response times should not exceed three seconds--Jim Marra said the hospital never considered waiting that long.

When DOS Is not Enough
As part of a merger with several major Boston-area health-care facilities, Brigham and Women's became part of Partners HealthCare Systems. Merging meant integrating several data processing facilities with more than 12,000 nodes. Again, Brigham and Women's faced a growth problem.

InterSystems representatives, continuing to look for ways to improve Open M, asked me to evaluate this project. They were replacing DOS with NT and about 100 servers. I thought they'd lost their minds. I couldn't understand why InterSystems was testing NT.

Then came NT 3.51. Here was the product InterSystems needed to fit its vision. It now had the next generation of Open M, and the hospital had the tools to open its system to more growth.

Why NT?
InterSystems and Brigham and Women's chose NT for several reasons. Clearly, NT had to offer technical merit because getting the job done was the highest priority. InterSystems liked NT because it simplified the Open M application's architecture. Although the data switches were a clever workaround, NT's superior architecture let InterSystems create more than enough connections to eliminate this additional layer of processing.

When I asked Jim Marra why Brigham and Women's chose NT over NetWare, he told me something I didn't expect. The hospital's confidence in Novell's support for a development project was low. In contrast, the MIS staff's experience with Microsoft's support made them comfortable with NT.

Paul Grabshied of InterSystems told me the choice of NT was also customer driven. "We make choices to match what our customers want (within reason), and we saw a demand for NT even at version 3.1," he said.

InterSystems saw three major advantages to using NT as a successful platform for Open M. First, NT's hardware demands are light, making boxes running NT inexpensive--a crucial element in InterSystems' application architecture. Second, NT provides quality integrated networking, which is also crucial to link the distributed database. And InterSystems liked NT's Symmetrical MultiProcessing (SMP) support; it offered high power at low cost. In addition to NT, InterSystems will continue to support Open M on DEC platforms with a version for Digital's Alpha RISC-based chip.

Not Just for Hospitals
Although InterSystems' Open M has its origins in the medical industry, all OLTP systems share the same needs, regardless of the type of data they handle. Any OLTP application can use Open M. InterSystems gets about 25% of its business outside the medical market.

Open M is available for several mainframe and midrange systems; now, NT's innovative, distributed architecture is promising. You can configure the Open M for NT and Win95 architecture in several ways, from an inexpensive single-user environment to a three-tier environment that separates the functions of data presentation, application logic, and database services.

End of Article