Alert Based Monitoring of Stock Trading Systems
Edward W.Y. Ho 1, Dickson K.W. Chiu2, Senior Member, IEEE, and Patrick C. K. Hung3
1
Department of Computer Science, Hong Kong University of Science and Technology
2
Department of Computing, Hong Kong Polytechnic University
3
Faculty of Business and Information Technology, University of Ontario Institute of Technology, Canada
email: hoed@ust.hk, dicksonchiu@ieee.org, patrick.hung@uoit.ca
Abstract
Nowadays, stocks are traded electronically instead of
manually with open outcry approach. As a result, business
activities of investment banking organizations rely heavily
on the availability of their trading systems. Any system
failure will directly affect their business and in turn damage their reputation. Due to the complexity of the business,
trading of stock requires services provided by many systems even within the same company. Any failure of a single system may stop the business. However, the monitoring of many systems simultaneously is not an easy task.
This paper proposes a Web service approach to monitor
all the systems related to stock trading within an investment banking organization. We develop a model for specifying how to detect potential system problems quickly, how
to escalate the issues to relevant parities on time with an
alert mechanism, and how to manage system outages
properly.
1. Introduction
Recent advances in telecommunication systems and
Internet technologies have made the flow of news and
information among investors and investment banking organizations more rapidly than ever. Investors are now
much more knowledgeable. They feel quite comfortable
to place stock orders without consulting a financial advisor.
Furthermore, Internet technologies allow investors to send
orders easily with mobile phones or Internet browsers to
all markets in the world. As a result, the demand of getting more services from the financial industry has been
growing quickly for the recent ten years. To cope with
such demand, the stock exchanges of many countries have
implemented electronic trading systems, which allow brokers and financial institutions to hook up their trading systems to the stock exchanges’ trading platform [1]. For
instance, the Hong Kong Exchange (HKEx) has established the Open Gateway (OG) for brokers and financial
institutions to connect their own trading systems to the
HKEx’s servers [2].
To allow routing of stock orders to the stock exchanges electronically, investment banking organizations have to
develop new trading systems to meet the specifications of
the message standard of the stock exchanges. These new
trading systems have to be connected to other internal systems to complete the transactions. The life cycle of an
order is illustrated on Figure 1.
Order Capture
Validation of order
And client information
Order Management
Store order Information
and keep track of status
Execution
Sending orders to
stock exchanges
or external brokers
Settlement
Payment by cash and
Transfer of stocks
Figure 1. Order Life Cycle
As the trading systems are so critical to the business
of the investment banking organizations, they must be
monitored closely. Any potential issues must be first notified to the technology staff. Technology staff must then
determine how to resolve the issues and escalate to the all
the affected parties.
This paper proposes an alert based approach to monitor different types of trading systems (order management,
execution, settlement, etc.), based on our case study in a
large global investment bank. The new monitoring system,
known as Stock Trading Monitoring System (STMS), detects system issues quickly and informs relevant parties to
take action. When there is an outage, appropriate actions
can be taken as soon as possible to minimize the impacts.
After the issues have been resolved, all the detailed information such as symptoms, root cause, resolution, and preventive actions are recorded. All relevant staff can also
learn from experience how to prevent similar problems. If
the same problem occurs, the remedial actions can then be
carried out quickly.
The subsequent sections will firstly discuss the background information which includes motivation and related
work. Then the detailed description of the new monitoring
system is proposed. Finally, there are discussion, conclusion and future work.
2. Background and Related Work
Owing to the recent development of information technology and globalization of economy, large and global
investment banks have been developing many new systems in the recent 10 years. As a result, there are many
new systems running on the platform with cutting edge
technologies, but many old systems are still running on old
technologies in the enterprise. The new systems usually
provide Web interface for administration and monitoring.
Monitoring their status of is not difficult. However, the
old systems usually do not have sophisticated interface for
monitoring. In order to improve the efficiency and effectiveness in such a complex environment, a common way
to monitor all the systems becomes vital. We study the
trading system of an investment bank because of its importance to both the business and also the clients. The typical main components include:
Client Trading Systems – The clients (e.g. investment
management companies such as Fidelity) have their own
systems to store the stock orders. They send the orders to
the investment banks with brokerage services using the
FIX protocol [3] via leased lines or the Internet. The executions and the order status can be updated in real-time.
Client Settlement Systems – After trades are done,
payment instructions and how the stocks should be delivered are sent from the investment banks through the external stock and cash depository system. These systems monitor such transaction status.
Order Routing Systems – These systems capture the
orders from the client and validate them. If an order is
valid, it will be routed to the stock market of the target
country. For example, if the order is to buy a Japanese
stock, it will be routed to the order management system
which handles the Japan stocks.
Order Management Systems – They keep track of the
order status and record the quantities of orders have been
executed and their transaction prices.
Execution Systems (Manual & Automatic) – They interface between the investment banks and the stock exchanges or external brokers, typically with the FIX protocol (e.g., the Singapore stock exchange [4]). Manual execution systems require brokering staff to manually click
buttons to send orders to the stock exchanges or outside
brokers. In contrast, automatic execution systems send
orders to the stock exchanges or brokers automatically
according to a pre-defined algorithm [5].
Market Data Systems – They distribute the market information such as bid and ask prices of stocks, which brokers are trading on the market and financial news to other
systems. The data integrity and latency have a large impact on the execution systems.
Reference Data Systems – They store the static information of the clients such as credit profile as well as data
of the stocks such as the symbols (e.g., 0005.HK refers to
HSBC in Hong Kong market). Missing such data will stop
the client or stock from trading.
Settlement Systems – These refer to the settlement system of the investment banks. Their function is similar to
the clients’. The difference is that the investment banks’
settlement systems handle the trades of many clients while
the clients’ settlement systems handle only their own
trades
External Reference Data Systems – They provide reference data to investment banks’ reference data system,
such as Bloomberg, Standard & Poors, etc.
External Market Data Systems – They provide market
data to the market data system of the investment banks,
such as Reuters and stock exchanges.
External Stock & Cash Depository Systems – They are
systems of external parties who keep track of the payment
and the stocks clearance. Examples include commercial
banks and central clearing companies such as HKEx in
Hong Kong [6].
Client
Client
Trading
Trading
System
System
Order Routing
System
Client
Client
Settlement
Settlement
System
System
External
External
Reference
ReferenceData
Data
Vendor
VendorSystem
System
External
External
Market
MarketData
Data
Vendor
VendorSystem
System
Reference
Data
System
Market
Data
System
Stock
Stock
Exchanges
Exchanges
Order Mgmt
System
Manual
Execution
System
External
External
Broker
BrokerSystems
Systems
Settlement
System
Automated
Execution
System
External
External
Stock
Stock&&Cash
Cash
Depository System
Depository System
Figure 2. Trading platform of an investment bank
Figure 2 illustrates the interconnections of all the
components. It can be easily seen that all these components are highly inter-dependent. Therefore, a failure in
any one of them will affect the whole operations of trading.
Also, both old and new systems co-exist. Old systems typically include order routing systems, manual execution
systems, settlement systems, and the reference data systems. New systems typically include order management
systems, automated execution systems, and market data
systems. It makes support difficult. Furthermore, there are
external dependencies. For instance, if there are problems
with any of the external market data vendor systems, external reference data systems, stock exchanges, external
broker systems, or stock and cash depository systems, the
whole trading platform will be affected. The diagnosis
processes are often time-consuming and further complicated with user’s desktop problems or physical network
problems.
Recently, due to cost reduction, many investment
banks have outsourced system development to external
contractors and even to overseas (such as TATA in India
[7]). As a result, instead of having many project teams to
monitor their own systems, a single support team has to
monitor all the trading systems. Since resources are limited, the support team cannot manually login to all systems
to check. This organizational change drives the need for a
common and easy monitor system. When there is a problem, the support team can then escalate the problem details
to the relevant parties quickly.
On the other hand, the business environment of the financial industry becomes more competitive than ever.
Many clients (especially institutional ones) can directly
connect to the investment banks’ servers for services, such
as FIX protocol trading, online research reports. Any system problems can be easily revealed to clients and possibly spread to competitors. As electronic trading services
are not very differentiable, clients can easily switch to
competitors to get similar services upon repeated problems.
There are three types of common complaints from the
clients in this trading environment. Firstly, it is unable to
detect problems quickly. The monitoring of all systems is
not centralized. When one system fails, only a small group
of (technology) people are aware of it. Secondly, it is not
quick enough to take remedial actions to minimize the
impacts. After a system is recovered, other systems are
still disconnected from it because different systems are
being taken care by different teams. Clients are also not
notified of the progress of system recovery. Thirdly, similar problems are not prevented. There are no centralized
knowledgebase storing the details of the problems and
solutions or preventive measures to avoid similar problems. So, when similar problems happen again, it still
takes similar amount of time to fix the problems.
There have been technical papers on how to streamline the flow of alerts. For example, Chiu et al. [8] describe how to use Web services to implement alerts in
healthcare processes. However, it does not directly fit into
the financial service industry, which has a radically different business environment. Ng and Chiu [9] also propose
an emergency route advisory system but the context is
similarly inapplicable to the financial industry. Chiu et al.
[10] also describe about the distributed e-Monitoring System and how to use the Web services to monitor but it does
not address the problems found in the investment banking
organizations, such as existence of old and new systems,
etc. Therefore, we have a strong motivation to propose a
new approach to monitor mission-critical enterprise systems.
3. System Overview
The new stock trading monitoring system (STMS) is
designed to match the needs of all stakeholders which include external clients, internal clients, the technology applications project team, the technology applications support team, the technology infrastructure team, external
service providers, stock exchanges and external broker
firms (as illustrated on Figure 3).
External Brokers
Stock Exchanges
External Clients
Internal Clients
Securities Trading
Monitoring System
(STMS)
External
Service Providers
Technology
Infrastructure Team
Technology Applications
Project Team
Technology Applications
Support Team
Figure 3. Stakeholders of STMS
External clients include both institutional clients such
as Fidelity and retail customers. Internal clients are the
people who use the systems for their daily business operations. They are sales, traders, dealers, financial controllers,
and settlement officers. Applications project teams usually
refer to the team responsible for system development. For
example, they design the Index Arbitrage systems, FIX
engines, and the gateways to the stock exchanges. The
technology applications support team is responsible to
provide daily maintenance of all the applications. They are
the people who operate the STMS. The Infrastructure
teams are teams maintaining the hardware of the servers,
the desktop workstations, the database, and the network.
External service providers include market data vendors
such as Reuters, reference data vendors such as Bloomberg, wide area network (WAN) network providers such as
AT&T, telephone companies such as PCCW, and also
some external technology solutions provider that provide
maintenance of some services such as email. Stock exchanges are the official exchanges where stocks are traded
such as Hong Kong Exchange (http://www.hkex.com),
Singapore Exchange (http://www.sgx.com) and Australian
Stock Exchange (http://www.asx.com.au). External brokers are the broker firms which can execute the orders on
behalf of other investment banks. They are usually used in
the locations where infrastructure is relatively poor, finan-
cial regulations are strict, or the business size is not large,
such as the Philippines, China, and Malaysia.
Infrastructure
Infrastructure
Monitoring
Monitoring
Web
WebServer
Server
Central
System Monitoring
Web Server
Central
Outage Knowledge
Mgmt System
Web
Web
Service
Service
Adaptor
Adaptor
Checking
CheckingDaemons
Daemons
Running
Runningon
on
old
oldservers
servers
email
Central Outage Knowledge
Management System
Client
Client
System
System
Alert
System
Central
Transaction
Handler
Operator
Controlling Handler
Alert
Transmitter
Alert
Database
Alert
Tracker
The SMTS can be divided into 3 major subsystems,
which are Central Monitoring Server, Alert System and the
New
NewServers
Servers
With
Withweb
webservers
servers
Web Server
4. System Design
Incident
Matcher
As shown in Figure 4, the STMS can be logically divided into several components:
Central System Monitoring Web Server – The application support team can use a single console to see the status
of all servers. The technologies to be used between all web
components are WSDL, UDDI, and SOAP for better sharing of data and services.
Alert System – When there is a system problem or potential issue, the alert system sends messages to all interested parties by email, mobile phone, and/or external client systems. Some designated staff will be the primary
receivers of the message. If the message is not acknowledged within a certain time, it will be resent to a more
senior staff.
Web Service Adaptor – If the old systems do not provide Web services for monitoring, a Web service adaptor is
used to capture their status and pass the results to the central system monitoring web server. Status of the old systems may be obtained by executing some system-specific
commands or just examining the log file if there are no
better alternatives.
Infrastructure Monitoring Web Server – It regularly
checks the health of the network as well as the hardware
of servers such as CPU usage and disk space. It reports
the results back to the central system monitoring web
server.
Central Outage Knowledge Management System – It
stores the details of the problems and their resolutions.
Preventive maintenance can then be created from the
knowledge to avoid similar problems. When a similar
problem occurs, relevant information can be retrieved as
reference. Statistics can be generated to illustrate the frequencies of different types of problems. As a result, the
performance of relevant technology staff can be measured
against the statistics.
Incident
Database
Web Server
Console
Figure 4. Components of STMS
Web Services
Adaptor
Infrastructure
Monitoring
Web Server
Incident
Logger
Old
OldSystems
Systems
without
without
Web
Webservices
services
Central
Monitoring Server
mobile
Alert System
(To send out
Warning messages)
It is
Alert
Logger
New
NewSystems
Systems
with
with
Web
Webservices
services
Central Outage Knowledge Management System.
illustrated on Figure 5.
Support Team’s console
Figure 5. Architecture of STMS
The Central Monitoring Server consists of the Web
services adaptor, the infrastructure monitoring web server,
the central transaction handler, and the web server. The
Web services adaptor calls a number of remote checking
daemons running on the remote old servers to get the status. Such collected data include the status of whether any
specified processes are running, any application errors in
the log file that cannot be obtained by any Web services.
An example of error in log file is shown below:
10:56:06,027:: ERROR [AffinityThreadPool DispatchingThreadPool#1] -- Child order [ED1-3-3] has been
rejected: Cannot create an external reference for
The infrastructure monitoring web server use Web
services to check the health of hardware of various servers,
including the internal and external network. The central
transaction handler is the central commander, which gets
the results from other components and sends the commands to appropriate components to take actions. The
operator controlling handler is the interface between the
support team’s console and the central transaction handler.
It can control the parameters such as the severity of an
alert, user roles and permission, etc.
The Central Outage Knowledge Management System
stores the details of the outage and employs case-based
reasoning system to give suggestions to the support team
how to escalate and fix the problems quickly. The incident
logger validates the incident and writes it into the database.
The incident matcher creates indices of the incidents according to certain attributes. When a new alert is encountered, it will search the database to find the relevant cases
for reference. Users may login to the knowledge management system to use the search engine to find the relevant
cases to plan for project roll-out and preventive maintenance.
The Alert System is responsible to send alerts to all
stakeholders. The alert logger records the details of the
alert into the database. The alert transmitter determines
who should get the alerts according to the details of the
alerts. For example, if there is hardware issue, such as disk
90% full, the infrastructure team, the application project
team, and the support team will be notified. The clients
need not know about this. In contrast, if a stock order is
rejected because of missing client details, the external and
the internal clients should also be informed. The alert
tracker will keep track of who has acknowledged an alert
within a specified time. If there is no reply, the alert will
be escalated to a larger group or to a more senior level
person.
All the Web services provided by different subsystems employ SOAP for better compatibility and expansion. For example, if a new client joins and they request
for monitoring their system, the development time will be
much shorter.
Regarding the flow, an alert is the starting point.
When the central transaction handler receives a message
from other web servers, it considers that there is a real or
potential problem. It will then send a request to the alert
system, which will generate an alert. Simultaneously, the
central transaction handler will also send a request to the
central outage knowledge management system, which
creates a new incident and store it into the database.
The alert tracker uses a timestamp field in an alert to
store the time when it is sent. If there is no reply after a
specified time, the urgency will be increased. Depending
on the severity of the alert, the urgency does not necessarily start from the lowest one, say “Normal”. Let t be
elapsed time after the first alert is sent. Various actions
will be taken according to the example urgency policies as
illustrated in Table 1. The criticality is illustrated as follows.
0≤t<T
T ≤ t < T +t1
T + t 1 ≤ t < T + t1 + t2
T + t1 + t2 ≤ t < T + t1 + t2+ t3
T + t1 + t2+ t3 ≤ t
Urgency
Action
Normal
Urgent
Very Urgent
Critical
Very Critical
Normal
Urgent
Very Urgent
Critical
Very Critical
Submit the first alert to a group
Resubmit to the same group, reminding them
that deadline is close
Resubmit to a more senior staff of the same
group
Resubmit to all technology staff
Broadcast the message the all relevant staff
Table 1: Urgency Table
When an alert is created, an incident is also created.
According to the details given by the alert, the central outage knowledge management system uses various heuristics to retrieve the relevant cases and send short message
to the group of people same as those receiving the alerts.
The relevant staff can then use a web browser to retrieve
the details. The staff should update the incident and close
it after fixing the problem. If the incident is not closed
after a specified time, a new alert will be generated again
Of course, this alert will not create any new incident; otherwise there will be duplicated incidents and loops. Figure
6 illustrates the relation between incident, alert, owner,
system, individual and group while the high level data
structure is illustrated in the tables below.
System
1
1..*
1
1..*
Incident
Alert
1..*
1..*
1
1
Individual
Person
*
Owner
*
Group
Figure 6. Relationship of Data
ALERT
Fields
Source
Details
Urgency
Entered Time
Resolved
Owner
Timestamp
INCIDENT
Fields
Type
Alert
System
Symptom
Resolution
Root Cause
Severity
Dollar Impact
SYSTEM
Fields
Name
Description
Where problem is detected
Brief description
(Explained in Table 1)
Time when alert is produced
Yes or No
Person who acknowledge alert
Time where it was last touch
Table 2: Alert Record
Description
Hardware, software, etc
Related to alert record
Related to system record
Detailed description of the problem
Time when alert is produced
Cause of problem
High, Medium, Low, etc.
Real or potential loss in dollar value
Table 3:Incident Record
Description
Name of System
Owner
Description
Nature
Uptime
OWNER
Fields
Name
Nature
Rights
Contact Details
Uptime
Project manager
Brief description of system
Order routing, Order management, Execution, Settlement, etc.
24 x 7 or Mon – Fri, etc
Table 4: System Record
Description
Name
Group (G) or Individual (I)
Some can close incident, some can have
read-only rights
mobile number, email address, etc
24 x 7 or Mon – Fri, etc
Table 5: Owner Record
In order to have better communications with Web services, the messages will be in XML format. An example
of a new alert found in the automatic execution system
(AES)
<Alert>
<Source>AES</Source>
<Details>Order Rejected</Details>
<Urgency>Very Urgent</Urgency>
<EnteredTime>11:30:33</EnteredTime>
<Resolved>N</Resolved>
<Owner></Owner>
<TimeStamp>11:30:33</TimeStamp>
<Alert>
5. System Walkthrough Scenarios
Here is an illustrative scenario showing how the problems are detected, escalated, and resolved. The disk of the
order management system failed at 2:00pm. An alert was
sent to the infrastructure team, the application support
team, and the internal clients (sales and traders). After the
server team of the infrastructure team received the alert,
they acknowledged it. The acknowledgement was forwarded to the application support team and the internal
client to inform them that someone was investigating the
problem. Simultaneously, the application support team got
the relevant cases from knowledge management system.
They discovered that other systems including a manual
execution system and an automated execution system were
affected. Therefore, they inform the affected internal clients that other alternatives such as stock exchange trading
terminals should be used. After the internal clients were
informed, they redirected their orders to exchange terminals. The disk problem was fixed at 2:30pm. The server
team marked the alert to a CLOSE state and closed the
incident with details. Once the application team received
the alert with CLOSE state, they knew that problem was
fixed. They restarted some processes in the order management system and informed the internal clients, who
then resumed their normal operations.
Before the STMS was launched, the outage typically
lasted for 2 hours. The reason was that even after the server team knew and fixed the problem, the application support team and the internal clients were not aware of the
updated situation. The sales and traders still kept putting
order into the order management system and using the
execution systems. However, all the orders were stalled.
The sales and trades kept complaining that there was no
response but the application support team found that all
the processes were running although the CPU usage was
high. Finally, the support team called the server team to
find out the cause. After the processes were restarted in the
server, the problem was fixed. However, owing to 2 hours
outage, some external clients switched to another investment bank. Now with the help of the STMS, the outage
was reduced to 20 minutes.
Here is another scenario. Another system failure started from a network problem. There was a few minutes’
disconnection between Hong Kong and Japan at 3:00am.
Alert was sent to the infrastructure team (including the
network team, the market data team and the server team),
the application support team and the internal clients. The
network team acknowledged the alert and called the external network provider to investigate. It was decided to
switch over the WAN from the primary link to the backup
link. The problem was fixed at 5:00am. Once the market
data team knew that the incident was closed, they rebounced the market data server. When the application support team arrived at the office at 7:00am, they checked that
all processes ran normally. When the sales and trades
started using the trading systems at 7:30am, there was no
problem. Before the STMS was implemented, the network
problem made the market data system fail, which in turn
made the automated execution system operation go wrong,
i.e., orders with wrong prices were sent to the market.
There could be significant loss in that case. Now the
STMS significantly made the problem transparent to the
clients.
Some common issues that the STMS monitors are illustrated in the following table
Issues
Missing processes in server
Disk response time, percentage of disk
usage
Percentage of CPU usage
Packet loss in network
Latency of getting market prices
Type
Applications
Hardware
Hardware
Network
Market Data
Checking data content of market price
Market Data
Transaction rejected by processes
Applications
Orders rejected because of missing stock Applications
or counterparty
Response of an transaction longer than Applications
expected time (e.g. after an order is sent to
the stock exchange, there is no acknowledgement after 2 seconds)
Inconsistency of static data (stocks, cli- Applications
ents, users) between different applications
Missing data file (e.g. A list of restricted Applications
stocks is downloaded from the compliance
database to the trading database to prevent
trading for some stocks)
Checking the status of overnight jobs
Applications
Heartbeat missing (heartbeat is used to Applications
make that the connection between process
in servers and clients are active)
Table 6: Issues monitored by STMS
The STMS is designed to handle most problems
found in the trading environment. However, there will be
some exceptions and limitations. Some typical problems
are highlighted as follows, in which human attention could
be drawn for solving the problems manually.
During summer in Hong Kong, typhoons may lead to
half-day trading. For example, the stock exchange may
announce that trading to be halted at lunch time. As a result, there will be many alerts reporting that there is no
market data update in the afternoon. In this case, the support team may have to login to the system to manually
override some rules.
Furthermore, when the STMS cannot get the status of
some servers being monitored for a certain period of time,
it cannot distinguish whether it is a network problem or it
is a server problem (e.g., a system hangs). Manual intervention is needed to check what has happened.
The Web service adaptor is used to check the status of
the old systems. Some old systems actually run on nonEnglish platform such as Korean, Japanese, or Chinese.
Finding the errors from the log file may be very difficult.
As investment banks are global organizations, “follow-the-sun” support model is usually adopted. For instance, when there is a system failure in a server in Hong
Kong at midnight, the New York team should attend.
However, if the day is a holiday in New York, the alternative is London team. The holiday table is maintained in
STMS. If the holiday table has some wrong or missing
data, alerts may be sent to an incorrect destination. It will
make the response time of acknowledging an alert much
longer.
6. Discussion and Summary
The STMS has shortened the outage time and minimized the business impact. As shown in the cases in the
previous section, the infrastructure team and the application support team can now work closely to resolve issues.
The internal clients will be kept posted of the progress of
the problems. They can make better decisions during the
outage. It is even better that some problems are fixed before the clients can detect them. For example, if there is
inconsistency of static data among different systems, such
as a new stock, the operations department can rectify them
before the data is used. As a result, when the external clients send an order of the new stock, there will be no problem. In contrast, orders will be rejected. Nowadays,
hardware cost is much cheaper that human cost. After the
STMS is launched, new systems can be easily monitored.
No additional support staff is normally required. It is
planned to use STMS in all offices.
However, there may be problems in some countries
where the language and infrastructure have limitations.
People in some countries may not comprehend English
very well. Having multi-lingual support of the STMS is a
big effort. Having local language interface for some important modules is possible but it will take extra time and
cost to build it. Also, initially, false alarms may occur often. It takes some time to filter out the wrong one. In long
term, it is hoped that the investment banking organizations,
the stock exchanges and the external vendors can develop
more Web services to make the monitoring process more
efficient.
The main future work is to evaluate the effectiveness
of this approach. In order to get more comprehensive
feedback, after the STMS has been launched for several
months, feedbacks have to be obtained from all level of
staff from various departments. For example, questionnaires should be sent out by email. Representatives from
each group of internal and external clients should be interviewed. On the other hand, we can evaluate whether the
same system problems can be avoided. The number can
easily be obtained from the incident records of the STMS.
If a particular team can reduce the outage significantly, the
results will be present to the management for appreciation
and rewards.
The Internet technology is evolving rapidly. Web service is the trend of communications between various systems. This Web service approach of monitoring the critical
trading systems should significantly reduce the response
time of rectifying system problems. Consequently, the
competitiveness of the company can be increased to a
higher level. We expect our alert based approach is general
enough and can be apply to most other organizations, in
which the criticality of application systems are general less
than the case that we have studied in this paper.
Order Received
Begin
Enquiry
Received
Check
System
Config
Prepare
Quotation
Send
Quotation
Send
Extra Info
Prepare
Service
Deliver &
Install
Install
Software
Test
System
Payment
Received
End
Request
Extra
Info
Sell Integrated System
Begin
References
Req
Extra
Info
Order
Missing
Parts
Assemble
System
Prepare Service
System
Integrator
[1] Hong Kong Monetary Authority, “Impact of Electronic
Update
Trading”, www.info.gov.hk/hkma/eng/research/RM16Begin
End
Catalog
2001.pdf
[2] Hong KongReceive
Exchanges
andUpdates
Clearing Limited, “AMS/3 sysPart Info
tem http://www.hkex.com.hk/infra/ams3/ams3.htm
[3] FIX Protocol Limited, “What is FIX ?”,
http://www.fixprotocol.org/what-is-fix.shtml
[4] Singapore Stock Exchange, “Trading System”,
http://www.sgx.com
[5] Investopedia”, “What is algorithmic trading”,
http://www.investopedia.com/terms/a/algorithmictrading.as
p
[6] Hong Kong Exchange and Clearing Limited, “CCASS/3”,
http://www.hkex.com.hk/infra/ccass3/ccass3.htm
[7] TATA group, “IT Services”, http://www.tata.com/
[8] Dickson K.W. Chiu, Benny W. C. Kwok, Ray L. S. Wong,
S.C. Cheung, Alerts for Healthcare, 2005.
[9] Cherrie W.W. Ng and D.K.W. Chiu. “e-Government Integration with Web services and Alerts: A Case Study on an
Emergency Route Advisory System in Hong Kong,” 39th
Hawaii International Conference on System Sciences, Jan
2006.
[10] Frank K.W. Cheong, Dickson K.W. Chiu, and S.C. Cheung.
“Developing a Distributed e-Monitoring System for Website
and Web services: An Experience Report with Free Libraries and Tools.”, 2005
End