Nasdaq SDR - A Real-Time, High Availability Windows NT Based Solution

Archived content. No warranty is made as to technical accuracy. Content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

"Nasdaq's new Surveillance Delivery Real-time system is an alert detection and presentation system that is unmatched in its speed and ability by any other financial market in the world, said Gregor S. Bailar, Executive Vice President and Chief Information Officer of the National Association of Securities Dealers, Inc. (NASD®) the parent of The Nasdaq Stock Market. "After thorough testing, we have created a state-of-the-art system that will help to maintain a level playing field for shareholders and protect the integrity of the marketplace for all participants."

On This Page

Overview
The Challenge
The Team
The Development Cycle
Business Process Workflow
Software Architecture
Hardware Architecture
System Management
The Future
Summary

Overview

The Nasdaq Stock Market®, the world's first electronic market and largest stock market by dollar and share volume, has become the model for developing exchanges worldwide. Nearly 5,000 companies—including both small, quickly growing companies and many large corporations that have become household names—trade their securities on Nasdaq®.

Recently, Nasdaq created the Surveillance Delivery Real-Time (SDR) System, a mission-critical software application that tracks stock market events and issues alerts at the possibility of any abnormal market activity.

Historically, mission-critical applications have been developed on midrange systems running UNIX or high-end computing platforms operating under mainframe operating systems. The SDR system is a bellwether application that provides clear proof that the Microsoft® Windows NT® 4.0 operating system running on mainstream Intel architecture can successfully deliver mission-critical functionality.

This paper presents the challenges that confronted Nasdaq as it developed this application. Following an introduction to the team that is credited with designing, developing, and implementing SDR, the technical solution is explored in detail. This paper presents the development cycle for SDR in support of the rapid design-to-implementation schedule required for the application. It explains the business process, application architecture, system features, and specific deliverable components as well as the hardware solution supporting the high availability requirements for SDR. Finally, the paper explains the systems management tasks for the SDR application as they relate to overall operations.

SDR, running in a Windows NT 4.0 and Intel environment, delivers:

• Real-Time Information: examining more than two million transactions during each trading day (over 200 transactions per second), filtering for criteria that flags alerts, and delivering alerts to analysts within two seconds.

• Reliability: providing 99.97 percent uptime, and extensive failover procedures.

• Scalability: To take advantage of multiple processors, the design features eliminate the need to rewrite code when larger than four-way processors are introduced to the system. This scalability has been proven on a Unisys QS/2 10-processor test system. Now in production, SDR has easily passed benchmark tests that more than tripled the current level of transaction activity.

• Flexibility: accommodating changes in logic, filters, rules, and other programmed elements without the need to re-engineer the software.

• Security: protecting the system with a closed environment.

SDR uses commodity hardware running Windows NT 4.0:

Servers

• Unisys Aquanta QR/2

• Four-way using 500 MHz Intel® Pentium® III Xeon™ processors

• Unisys OSR 5000 RAID 10 on database servers

• Disk Mirroring on non-database servers

• 2-GB memory in the Alert Engine and database servers

• 512-MB memory in other servers

Workstations

• Networked PC running Windows NT 4.0

• Intel® 266 MHz Pentium® Processor

• 128 MB RAM

• VGA video

SDR was developed in the Microsoft Visual C++® development system using the Microsoft Windows® Digital Network Applications architecture and is implemented with out-of-the box software:

• Microsoft SQL Server™ 6.5 with Service Pack 5A (future phases of SDR are being developed in SQL Server 7.0)

• Microsoft Transaction Server (MTS)

• Microsoft Message Queue Server (MSMQ)

• Microsoft Clustering Server

• Microsoft Management Console

• WBEM (Web-Based Enterprise Management used on the Operator's Console)

The Challenge

The Nasdaq's MarketWatch Department was created to facilitate regulatory oversight of The Nasdaq Stock Market. The MarketWatch mandate is to protect the integrity of the marketplace in order to maintain a level playing field for investors. MarketWatch analysts examine activities that appear to be unusual, and determine whether intervention is required. The MarketWatch Department is divided into StockWatch and TradeWatch Sections. StockWatch is responsible for the real-time surveillance of issuer activity and the TradeWatch Section provides real-time monitoring of trading activity.

Intervention can take the form of correction of an erroneous financial figure or even a halt in trading for a particular stock. All intervention procedures require immediacy in order to be effective. To make the best use of their own expertise, the MarketWatch analysts require real-time data that contains accurate and relevant information, and access to historical data that puts the current information into perspective.

Current Environment

Prior to the development of SDR, MarketWatch utilized a Tandem-based application to monitor market behavior. Although this legacy application delivered valid detection processes, there was still a need to perform some time-consuming manual processes in order to review and identify additional alert conditions. This process eventually became cumbersome to keep up with today's marketplace. Internet trading has grown to 20 percent of Nasdaq's total shares traded, according to National Association of Securities Dealers (NASD) Executive Vice President and Chief Information Officer Gregor S. Bailar. The characterization and patterns of Internet trades are different than those of the traditional institutional traders. Nasdaq's MarketWatch department determined that additional automated alerts could help monitor market integrity in a more efficient and timely manner. MarketWatch would also benefit from the integration of data (historical, transaction detail, and alerts) into one comprehensive tracking system. Further, Nasdaq wanted to redesign the alert generation process to be more flexible, making it responsive to changing standards, rules, and market conditions.

The Requirements

In order to meet these objectives, an application would have to perform the following tasks:

• Analyze each Nasdaq market.

• Identify alert scenarios.

• Deliver alerts to the appropriate MarketWatch analysts within two seconds of the arrival of market information.

• Supply all relevant alert-related data to MarketWatch analysts.

• Recognize ownership of an alert upon analyst acceptance of the alert.

• Ensure security and enable auditing of all information collected and delivered to the MarketWatch group.

These objectives and needs are specific to the context of the Nasdaq Stock Market environment. The Nasdaq marketplace is electronic. Complicated financial transactions are completed in minutes rather than days and a transactional error could have immediate and far-reaching results.

In addition, technological advancements, electronic commerce, and the ever-increasing availability of high-speed Internet access have resulted in radical changes to the corporate environment. Businesses around the globe are reinventing themselves into highly adaptable, flexible, and virtual economic organisms. The most efficient organizations have the capability to conduct multiple business transactions simultaneously, regardless of the physical location of any participant.

In order to have both the StockWatch and TradeWatch sections of MarketWatch meet the overall objective of providing a fair and orderly marketplace, Nasdaq must be fully empowered to meet the demands of its investors. This means having instant access to relevant data and processing that data immediately for analyst review.

Nasdaq developed a Request For Proposal (RFP) for a mission-critical software application that runs in a PC environment. Nasdaq identified the various user groups that either use or take advantage of the features delivered by the Surveillance Delivery Real-Time System. The primary users of the system were identified as:

• StockWatch and TradeWatch analysts.

• MarketWatch operations managers (including alert administration).

• MarketWatch management.

Other groups that were identified as indirect beneficiaries of the information provided by the application included the following:

• NASD Regulation, Inc.

• NASD Economic Research Department.

• System administrators.

• Other future users.

Nasdaq's Information Technology (IT) department has a thorough understanding of both the Windows and UNIX platforms. There are clearly defined network management and maintenance procedures for such tasks as server backup and restore, online recovery, and server management. With this existing infrastructure and expertise in place, the RFP requested an open platform solution utilizing either the Windows or UNIX platform and delivering reliability to a minimum level of 99.97 percent (or just under one hour of operational downtime per year).

Ultimately, a Windows-based solution was chosen for this mission-critical application, because the Microsoft distributed Component Object Model (COM), Microsoft Transaction Server, and Microsoft Message Queue services provided the following desirable features:

• Reliability to 99.97 percent uptime (operational downtime of under 19 minutes per year given a 7.5 hour trading day).

• Utilization of Windows NT 4.0 authentication and security components.

• MTS and MSMQ interoperability with programs written in Visual C++.

• Capability to deliver a highly scalable set of application components.

• Modular flexibility, so that changes in functional scope or features to SDR would not require re-engineering of the program code.

The Team

With the Nasdaq development team driving the effort, three separate information technology firms worked to create the SDR software. Unisys Corporation, Micro Modeling Associates, and Microsoft brought to reality a solution that historically had not been considered possible in PC-based technology.

Nasdaq

Nasdaq defined the specifications and goals for the new application, as well as the environment within which SDR would be integrated. In addition, the Nasdaq IT department provided a wide range of expertise and operated as a full development partner.

Unisys Corporation

Unisys has been a Nasdaq partner for more than 25 years and has extensive knowledge of the operating environment and mission-critical enterprise systems. Unisys was involved with the SDR project from the earliest development stages. In defining the SDR architecture, Unisys defined an architecture that met two objectives. The first goal was to ensure that Windows NT would deliver the performance required for the SDR application. Simultaneously, this architecture created a benchmark application that would prove SDR's readiness. Today, Unisys provides comprehensive support for the Unisys server platforms, a critical element in operating enterprise-class applications for Windows NT.

Micro Modeling Associates

Micro Modeling Associates (MMA) is an eSolutions consulting firm and Microsoft's 1999 Solution Provider Partner of the Year. MMA's recognized technology expertise and extensive knowledge of the financial services industry made the firm an ideal technology partner to develop the detailed design and customized coding for the SDR project. The original SDR benchmark, designed and executed jointly by Unisys and MMA, proved that Microsoft Windows NT Server could handle the volume of transactions required for SDR. After delivering the benchmark testing, MMA was selected to develop the current application.

Microsoft Corporation

Microsoft has long stood firm in its position that the Windows NT platform is capable of providing high-end, reliable application support. Similarly, the Microsoft Windows distributed COM development platform and tools are flexible and scalable enough to create highly reliable solutions. In recognition of its commitment to both development and network platform, Microsoft provided its full support to the delivery of the surveillance system. Nasdaq has standardized its local area network (LAN) environment on the Windows NT platform, earning status as a premier Windows NT 4.0 and Windows 2000 Beta site. Microsoft has provided continuous network and development support, while Nasdaq delivers regular and significant feedback to Microsoft, including bug alerts along with related solutions.

The expertise and strategic relationships of all these partners created a cohesive, synergistic team that has delivered a robust, mission-critical application.

The Development Cycle

The timeline in Figure 1 chronicles the entire SDR application development cycle. The initial RFP for SDR was released in 1997, and design of the application began in April 1998. The development process began in November of that year and Phase 1 was completed in April of 1999.

Note: Phase 1 is the current implementation of the software and additional software features will be added in future phases of development.

The Quality Control testing stage of SDR was completed in August 1999, at which time it was introduced to the production environment in parallel with the existing system. The SDR application was deemed System of Record in September 1999.

Figure 1: SDR timeline

The SDR application development life cycle is classified by stages, as indicated in Figure 2.

Figure 2: SDR development life cycle

Design Stage

The Design stage of SDR was a five-month effort launched in July 1998 with the Project Initiation phase. At this time the developers identified the high-level application design and established the benchmark used as the basis for the detailed design.

Development Stage

In the Development stage, the program code was initially created, documented, assembled, and tested. The SDR Development stage began in November 1998, and continued until April 1999, when the application progressed to the Quality Control Stage.

Quality Control

The Quality Control (QC) stage is the primary testing phase. During this time, SDR was subjected to robust stress testing of all its elements, including:

• Functionality

• User acceptance

• Failover procedures

• Disaster recovery

• Logical errors

Bug fixes and code modifications were applied as needed during the QC stage. No additional features or software coding was introduced at this time. However, if any tests demonstrate severe problems with an entire subsystem, the project is returned to the Development stage. That did not occur in the SDR project. The SDR QC stage lasted until mid-August 1999, at which time the SDR application was introduced into the production environment.

Production

The Production stage starts with the application functioning in parallel with the incumbent software. Final testing and system parameter adjustments occur at this time without risking alerts, since the existing system is still in place. When ready, the software is fully deployed at a rate designed to prevent interruption of work. The SDR Production stage began in the middle of August 1999 and primary responsibility was scheduled for the application in early September.

Business Process Workflow

The SDR program is a three-tiered application, designed to monitor the market, generate alerts as appropriate, and store all data in a secure repository.

SDR scans transaction data from multiple sources and analyzes each transaction to detect any abnormal market condition, in order to ensure that all trading is being conducted properly. Because this data flows continuously, SDR has been designed to be reliable.

The surveillance and reporting responsibilities necessary for SDR to meet performance metrics are distributed across several servers, and Microsoft server clustering has been implemented within the SDR database environment to ensure high availability.

The diagram in Figure 3 represents a high-level view of the MarketWatch processes in SDR.

Figure 3: MarketWatch data flow processes

Alert Administration

The Alert Administration process maintains and implements the criteria standards used by SDR. The alert administration process is designed to support the following fundamental activities of the MarketWatch group:

Tune existing alert thresholds or create new alert algorithms based on changing market conditions. The system must allow the administrators to easily view and modify existing algorithms, and test the impact of modifications before putting them into production.

• Respond to market conditions such as a "fast market" by:

  • Changing roles and adding analysts to handle increased alert activity in scenarios such as fast markets.

  • Adjusting alert thresholds.

• Executing entitlement functions for SDR users.

Alert Detection Engine

This system component applies the logic supplied by administration to the information received from the dissemination servers. These inputs to the system create the source data from which alert generation decisions are made by the SDR application.

Alert Presentation

The Alert Presentation function publishes the alert to all authorized parties. It is important to note that the SDR service level expectation defines a two-second interval as the maximum amount of time allowed between the receipt of information from the dissemination servers and the publishing of an alert to MarketWatch analysts.

MarketWatch Tracking

This component of the SDR system provides the functionality the analysts need to track the progress of an alert from the moment it is selected by the analyst.

MarketWatch Statistics

The statistics function provides the MarketWatch Analysts with the ability to create ad hoc reports based on readily available data. Although SDR maintains this data, the analysts utilize Crystal Report Writer to design summary or management reports as needed for management or other approved purposes.

SDR Repository

The data repository archives contain all the alert data and background information necessary for an analyst to resolve the issue.

System Monitoring

Within SDR, each process has a heartbeat. One missed heartbeat raises a warning message; three missed heartbeats imply a component failure. This monitoring tool provides support for the following SDR services, which are described further in this document:

• Line Handler server

• Alert Engine

• Alert Dispatcher

• Analyst Server

Built-in redundancy for services and processes provide ongoing support for information flow, and server clustering enables redundant database support and server failover in the unlikely event of a hardware problem.

Software Architecture

Microsoft development tools are powerful, flexible, and integrated. When distributed COM is employed in conjunction with Microsoft Transaction Server, three-tiered applications can be readily developed. A three-tiered application is also referred to as server-centric because application components run on middle-tiered servers that function independently of both the presentation interface and database storage. While there is no requirement that each unit run on a different physical machine, to deliver maximum scalability and availability benefits, three-tiered systems must run with the following configuration:

• Presentation components on desktop clients or browsers.

• Application logic on middle-tiered servers.

• Data on dedicated database servers.

Client workstations do not process any data; they interface with the Analyst Server and display alert detail and history to authorized analysts.

The use of this three-tiered architecture enabled the development team to take advantage of the following features:

Replication of application components on multiple machines simultaneously.

This spreads the client load across multiple machines and enables higher availability, scalability, and performance. Application component replication (as opposed to data replication) is not possible with two-tiered Client/Server architectures because stored procedures must run in a single database.

Support for shared database connections.

This has the effect of lowering the number of total sessions the database server must support, thus improving performance.

Simplified Administration.

A common infrastructure allows for centralized security of all the middle-tier (application) components. Access can then be granted or denied on a component-by-component basis, which in turn simplifies administration.

Figure 4 represents Microsoft's depiction of a three-tiered application model:

Figure 4: Three-tier application model

Surveillance Delivery Real-Time Architecture

Using Figure 4 as a guide, the next figure (Figure 5) demonstrates the tiered architecture of SDR. This diagram depicts the SDR application in terms of the architectural segregation of the actual software components from both the database server and from the client presentation interface.

View Figure 5 System component architecture

Database Tier

This release of SDR utilizes Microsoft SQL Server 6.5. The database is used primarily to archive the alert information generated by the Alert Engine. High availability fault tolerance for the database servers is provided by combining mirrored drives in a striped set with parity (RAID 10).

RAID 10 delivers the same fault tolerance as RAID level 1 and has the same overhead for fault tolerance as mirroring alone. Server clustering is implemented on the database server to deliver the same level of redundancy and high availability that exists in all other SDR components.

Application Tier

There are three primary components in the application tier: The Line Handler; the Alert Engine; and the Alert Dispatcher. The Analyst Server component, which is represented in Figure 4, is actually installed on the Alert Dispatcher server.

Line Handler

The Line Handler Server is responsible for receiving input from various Nasdaq Dissemination Servers. The data is organized into a single stream and a common format, and the information is transferred to the Alert Engine.

In addition, the Line Handler Server administers Gap Detection. It is extremely important for the MarketWatch department to know that they have received every piece of data from the dissemination servers in the correct sequence. The Gap Detection function is fundamental to the accuracy of the information ultimately generated by the Alert Engine.

The Line Handler is also responsible for delivering quote-related data to the MarketWatch SQL database server. Quote data is used to provide additional supporting data to the Alert Dispatcher server and is discarded at the end of each day.

Alert Engine

The Alert Engine has a single but very critical purpose in SDR. This component analyzes data received from the line handler, compares this information against the criteria established through the alert administration process, and determines whether an alert should be generated and dispatched to the MarketWatch analysts. Due to server redundancy, the Alert Engine must process transactions generated from both Line Handlers, discard the duplicate information, and then apply the criteria to determine alert status. Given the two-second processing requirement for the Alert Engine, this component must operate with consistent and aggressive speed in order to meet the constraints.

Alert Dispatcher

The Alert Dispatch server is responsible for sending all alerts to the analysts' workstations. Simultaneously, this alert information is sent to the SQL Server database for archival purposes. These actions also take a significant amount of time to process, though nowhere near the intensity of the Alert Engine. Service level expectations have been established for transactional processing between the Line Handler and the Alert Dispatch server. A maximum interval of two seconds is allowed between the receipt of data from the dissemination servers to the dispatch of an alert to the Analyst Workstation.

Analyst Server

The Analyst Server performs two roles. It is the network layer component of SDR that actually supplies the Analyst Client with alert related information. In addition, this service delivers history and detail to the database server for future use. This component resides in Microsoft Transaction Server and utilizes MTS features to enforce security.

Client Presentation Tier

The Analyst Client software and system support interface utilities exist within this tier. Presentation features for the MarketWatch analysts, and support-based interface screens used by the system operators, are the primary features. Customized graphical alert screens and other output are maintained and controlled by the SDR client-side application residing locally on each computer. This level of client functionality is necessary for the successful performance of SDR.

Hardware Architecture

The hardware components are designed to support all the requirements built into the specifications for SDR.

SDR Server Platform

SDR utilizes 11 Unisys QR/2 four-way servers running the Intel 500 MHz Pentium III Xeon processor. The configuration of the servers is designed to support high availability and operates on Windows NT Server 4.0 Enterprise with Service Pack 4.

The hardware takes full advantage of the technologies available in the components:

• 100 MHz System Management Bus.

• Intel® 500 MHz Pentium® III Xeon™ processor with up to 2 MB L2 cache.

• Cacheable address space up to 8 GB.

• Glueless multiprocessing support for up to four processors (supports eight-way and beyond systems through other clustering technologies).

• Intel® Extended Server Memory Architecture with expanded 36-bit memory support that allows operating systems and applications to utilize memory greater than 4 GB.

• Thermal sensor that allows the system to manage thermal conditions actively.

• Error Checking and Correction (ECC) to maintain the integrity of data.

• Functional Redundancy Checking (FRC) to confirm processing integrity.

• System Management Bus (SMBus) for efficient communications between the processor, thermal sensor, processor-specific PIROM, OEM-writable EEPROM, and the rest of the system.

• Four 500-watt hot-swap power supplies (fourth power supply provides redundancy).

Unisys Add-Ons

Unisys has incorporated a great deal of advanced technology into the Aquanta servers delivered to Nasdaq, in order to deliver the indispensable attributes of scalability, availability, manageability, and interoperability traditionally delivered by mainframe-class systems.

Cache memory. To ensure maximum performance of the processors, the systems include third-level cache on the processor board.

Support for evolving clustering capabilities. The Servers support failover and scalability clustered environments, such as Microsoft Cluster Server.

Client Platform

As mentioned in the overview section of this paper, the SDR client runs on a standard Intel® desktop. The SDR development team recommends the following minimum configurations as all of the Quality Control testing was performed on desktops with these characteristics:

• 266 MHz Pentium processor

• 128 MB RAM

• 2.1 GB IDE hard drive

• VGA or SVGA video resolution

• Ethernet Interface Card

System Management

The SDR application is a mission-critical application to Nasdaq and the MarketWatch department, and needs to perform functions that are vital to the ongoing health of the organization. The SDR system is mission-critical because it performs the functions for which the MarketWatch Department exists. Further, individuals who trade on Nasdaq, as well as the listed companies, have vested interests in the accurate monitoring performed by SDR.

Current trading volume has resulted in approximately 350 MB per day of dataflow passing through the monitoring system at a rate of 100 to 500 messages per second. MarketWatch archives approximately 4 GB of alerts per day.

Manageability

For a mission-critical application to be successful, several well-defined criteria have to be met in order to make the system manageable. SDR is designed with stringent criteria.

Availability

Availability is usually measured in percentages, with minimum downtime set at 99.97 percent. Nasdaq has defined the SDR minimum availability during operating hours at 99.97 percent. At this level, the maximum downtime is less than ten minutes per year. With a 7.5 hour trading day, the maximum acceptable downtime per year is calculated as (((7.5 * 5) * 52) – (7.5 * 8)) *.03= 56.7 minutes per year. The SDR system is mandated to recover in 15 minutes, with maximum loss of data no more than 30 seconds. Disaster recovery tests have surpassed these corporate requirements without any notice of the failover by the users of the system.

Redundancy

At the system level, the SDR application has been designed with triple redundancy. Fault tolerance is employed on each server. Each SDR system component (Line Handler, Alert Engine, and Alert Dispatch) has at least one redundant server for failover purposes and the entire SDR system has a fully functional remote "Hot Site" that is always running in tandem with the primary location and can assume full SDR responsibilities within 15 minutes. Within the SDR component groups, there are two Line Handler servers, three Alert Engines, two Alert Dispatchers, and two Database servers. The Database servers utilize Microsoft Clustering service in order to provide the same level of redundancy as all other SDR components. The database server is mirrored, utilizes RAID 10 for fault tolerance, and incorporates Microsoft Clustering Service (MSCS), which provides full server failover support.

Scalability

In order for an application to be successful, it has to be able to handle varying workload levels with consistency and dependability. The following table shows the SDR scalability values.

Table 1 SDR scalability values

Measurement Category	Shares traded on the Nasdaq per day	Computing Transactions per Day	Peak Values
Actual Trading Volume	1,000,000,000	2,000,000	300/Sec
Surveillance Delivery Real Time system	2,000,000,000	5,000,000	450/Sec
SDR Upper Limit	4,000,000,000	See Footnote [1]	See Footnote [1]

[1] These items have not been verified by the SDR development team and no extrapolations have been calculated here

Analysis of the data in this table reveals the scalability of SDR. The number of shares traded on Nasdaq averages one billion per day, which translates to approximately two million electronic transactions per day. The SDR system was benchmarked to operate normally at double this value and scale easily to four billion shares daily. If one billion shares are traded on Nasdaq, two million transactions will need to be processed through SDR. Assuming a 7.5 hour trading day, the calculation for transactions per second are as follows: 2,000,000 * ((7.5 * 60) * 60) = 75 transactions per second. A similar calculation at the five million transactions level reveals 185 transactions per second. Both activity levels are well within their relative peak activity-per-second value.

Since the conversion between shares traded to electronic transactions appears exponential, additional benchmarks were defined for the upper limit of transaction processing capability. This value of 450-per-second is a peak value best described as reflecting temporary surges or spikes of trading activity, and is not meant to be applied to the entire trading day. To prove this point, a simple calculation of this peak value against a 7.5 hour trading day indicates 12 million transactions per day. This value is large enough to exceed the SDR upper limit of both shares traded and electronic transactions completed per day.

Flexibility

The ability of SDR to incorporate logical and/or structural changes to its operating programs without having to be re-engineered is made possible through the use of Visual C++ and distributed COM. This flexibility is very important. The downtime and expense to recode an application would be unacceptable in this environment.

Security

Another consideration when implementing a mission-critical application is the security of the information and resources. Nasdaq relies on the Windows NT security system to authenticate users who have rights to the SDR subnet. Once the system has identified the analyst, an internal filter is applied to determine what entitlements or features are available to that user based on his/her login ID. The analyst's network login ID corresponds to a user database contained within the SDR system. This database identifies the level of authority and the SDR resource the person is permitted to access.

The SDR system servers are physically separated from the analyst's area and are secure within the Nasdaq data center. An isolated subnet protects the system from unnecessary network traffic, and Microsoft Transaction Server assists in providing access only to authorized personnel.

The Future

Nasdaq is moving towards the new millennium with an eye to the future. Already a beta site for the Windows 2000 operating system, migration plans are being developed. The SDR development team is also revising and enhancing the SDR application with the knowledge that a migration into the Windows 2000 platform is inevitable. The anticipation is that Windows 2000 will only strengthen the existing benefits of SDR and remove challenges. The current platform is providing a successful springboard and creating a positive legacy for the future. Nasdaq is planning to migrate their Microsoft SQL Server 6.5 database to SQL Server 7.0, with ultimate plans to become an early adopter of SQL Server 7.5.

Nasdaq plans to begin testing Unisys's new esPerformance, esUptime and esManagement suite of software on the ES 5000 platforms. These products further enhance the capability of Windows NT to support important applications. Nasdaq will also evaluate new servers based on Unisys's advanced Cellular Multiprocessing (CMP) architecture, designed to provide true mainframe-class computing on Intel processor-based systems. The systems are scheduled for availability in 2000.

Summary

The Nasdaq Stock Market developed the Surveillance Delivery Real-Time System as a mission-critical application using open technology on high-end Intel Pentium class servers. This aspect of SDR makes it interesting and valuable to the development platform upon which it was created, the networking environment within which it resides, and the development team that brought this application to fruition.

The Challenge

Nasdaq needed to monitor its markets and ensure a fair trading environment for stockholders and investors alike. As the dynamics of the business environment have changed over the past several years, corporate structures and activities have changed to meet the challenging new demands facing them. In a much faster environment, Nasdaq identified a need to react quickly to rapidly changing market environments, and the application that had been supporting the alert process was no longer seen as strategically sound. The application that was ultimately chosen had to be able to analyze market transactions, identify various scenarios, and deliver all relevant alert information to the analysts within a very short period of time.

The Team

An application as vital and robust as SDR has some naturally proud developers. Likewise, it could only take a strong team to develop such an application. This paper identified the vendors: Unisys, MMA, and Microsoft, which helped to create this application and pointed out the strengths they brought to the development table.

System Architecture

With just-in-time technology and very rapid time-to-market schedules, the SDR team needed a fast development cycle in order to bring the application to production quality in a very short period of time. This document explored and reviewed the process they embraced for the development of SDR. Also, the programming language and programming model that were used to guide the creation of SDR were discussed thoroughly.

System Management

For an application to be mission-critical it has to meet several criteria. This paper covers the areas of reliability, scalability, redundancy, and flexibility within the context of SDR, explains how the application satisfied the criteria, and discusses the importance and relevance of these high availability requirements.

The information contained herein is based on copyrighted information of The Nasdaq Stock Market Inc.