Description
The speed of todays processing systems has moved classical data warehousing into the realm of real-time.
Gravic, Inc. White Paper
The Evolution of Real-Time Business Intelligence
and How To Achieve It Using Gravic Shadowbase
®
A Gravic, Inc. White Paper
The Evolution of Real-Time Business Intelligence and How to Achieve it Using Gravic Shadowbase
®
Gravic, Inc. White Paper Page 2 of 33
Executive Summary
In today’s competitive environment with high consumer expectation, business
decisions based on the most current data available to the enterprise are the
ones that will improve customer relationships, increase revenue, and
maximize operational efficiencies.
The speed of today’s processing systems has moved classical data
warehousing into the realm of real-time. The result is real-time business
intelligence (RTBI). Business transactions are fed as they occur to a real-time
business-intelligence system that maintains the current state of the enterprise.
The RTBI system not only supports the classical strategic functions of data warehousing for deriving
information and knowledge from past enterprise activity, but it also provides real-time tactical support to
drive enterprise actions that react to immediate events. As such, it replaces both the classical data
warehouse and the enterprise application integration (EAI) functions. An RTBI system with a consolidated
real-time view of the business across the enterprise enables the provision of new business services
(applications) which were previously impossible, achieving competitive advantage.
Real-time business intelligence is also known as event-driven business intelligence. In order to react in
real-time, a business intelligence system must react to events as they occur – not minutes or hours later.
With real-time business intelligence, an enterprise can establish long-term strategies to optimize its
operations and maximize competitiveness while at the same time reacting with intelligence to events as
they occur.
In this white paper, business intelligence is tracked from its early days as a strategic tool to today’s real-
time capabilities for tactically responding to events as they happen. In conclusion, descriptions of the
Shadowbase suite of products from Gravic, Inc. are described, as well as several case studies where the
products are deployed. Shadowbase solutions are available today for achieving real-time business
intelligence.
The Evolution of Real-Time Business Intelligence and How to Achieve it Using Gravic Shadowbase
®
Gravic, Inc. White Paper Page 3 of 33
Table of Contents
Business Intelligence .............................................................................................................................. 5
The History of Business Intelligence ...................................................................................................... 6
The Early Days of Computing ............................................................................................................. 6
The Data Warehouse .......................................................................................................................... 6
Offline Extract, Transform, and Load .................................................................................................. 7
Data-Mining Engines ........................................................................................................................... 9
Reporting Tools ................................................................................................................................... 9
Data Marts ......................................................................................................................................... 10
Enterprise Application Integration ......................................................................................................... 11
Intersystem Communication with EAI ............................................................................................... 11
Adapters ........................................................................................................................................ 11
Message-Oriented Middleware (MOM) ......................................................................................... 12
Data Replication ............................................................................................................................ 12
EAI Networks .................................................................................................................................... 14
EAI and Business Intelligence .......................................................................................................... 15
Operational Business Intelligence ........................................................................................................ 15
Real-Time Business Intelligence .......................................................................................................... 16
Yesterday’s Data is No Longer Sufficient ......................................................................................... 16
Today’s Business Intelligence Needs ............................................................................................... 16
Real-Time Business Intelligence Systems ........................................................................................ 17
RTBI Dashboards.............................................................................................................................. 18
Online ETL ........................................................................................................................................ 19
Adapters ........................................................................................................................................ 19
Message-Oriented Middleware ..................................................................................................... 19
Data Replication ............................................................................................................................ 20
Online Copying.................................................................................................................................. 21
Extreme Availability ........................................................................................................................... 21
The Operational Data Store – The Next Evolutionary Step? ............................................................... 22
What is an Operational Data Store? ................................................................................................. 22
The Evolution of RTBI to ODS .......................................................................................................... 23
Real-Time Business Intelligence Solutions from Gravic....................................................................... 25
Shadowbase Software – Real-Time Replication .............................................................................. 25
Extreme Availability with Shadowbase Active/Active Support .......................................................... 26
Shadowbase SOLV – Online Copying .............................................................................................. 26
Shadowbase Streams ....................................................................................................................... 27
Shadowbase Real-Time Business Intelligence Case Studies .............................................................. 27
Fraud Detection................................................................................................................................. 27
Investment Product Promotion .......................................................................................................... 28
Tactical Reordering and Strategic Marketing .................................................................................... 29
Travel Analysis and Profiling ............................................................................................................. 30
Summary .............................................................................................................................................. 31
Gravic, Inc. Contact Information ........................................................................................................... 28
International Distributor Information ..................................................................................................... 28
Breaking the Availability Barrier Book Series ....................................................................................... 29
About Gravic, Inc. ................................................................................................................................. 29
Gravic, Inc. White Paper
The Evolution of Real-Time Business Intelligence and How to Achieve it Using Gravic Shadowbase
®
Page 4 of 33
Table of Figures
Figure 1 - The Data Warehouse ................................................................................................................... 7
Figure 2 - ETL: Extract/Transform/Load....................................................................................................... 8
Figure 3 - Sample Reporting Tool ................................................................................................................ 9
Figure 4 - Sample Digital Dashboard ......................................................................................................... 10
Figure 5 - EAI Intersystem Communication ............................................................................................... 12
Figure 6 - EAI Intersystem Communication ............................................................................................... 13
Figure 7 - EAI Networks ............................................................................................................................. 14
Figure 8 - A Fraud Detection OBI System ................................................................................................. 15
Figure 9 - A Fraud Detection RTBI System ............................................................................................... 17
Figure 10 - A Real-Time Business Intelligence Example ........................................................................... 18
Figure 11 - Sample RTBI Dashboard ......................................................................................................... 19
Figure 12 - Data Replication ...................................................................................................................... 20
Figure 13 - The Operational Data Store ..................................................................................................... 23
Figure 14 - The Evolution of the Operational Data Store ........................................................................... 24
Figure 15 - Real-Time Business Intelligence for Fraud Detection ............................................................. 28
Figure 16 - Investment Product Promotion ................................................................................................ 29
Figure 17 - Real-Time Business Intelligence for Parts Distribution ........................................................... 30
Figure 18 - Real-Time Business Intelligence for Travel Packaging ........................................................... 31
Gravic, Inc. White Paper
The Evolution of Real-Time Business Intelligence and How to Achieve it Using Gravic Shadowbase
®
Page 5 of 33
The Evolution of Real-Time Business Intelligence
and How to Achieve it Using Gravic Shadowbase
®
A decade ago, it was enough for a store to remain competitive if it could determine that battery-operated power
drills were hot items and were sufficiently stocked. That ability is no longer adequate in the current aggressive
marketing environment. Today that same store needs to know that a customer who is purchasing a set of drill
bits bought a battery-operated power drill the prior month. While the customer is at the register, the store offers
him a 30% discount on an extra drill battery for purchase during his next visit. Similarly, the store offers an
online customer with a similar purchasing history the same 30% discount during his current shopping session.
This requirement for current information is needed across the board, and even aids in life-saving and rescue
operations. A decade ago, a blood bank was considered successful in meeting the needs of a community if it
could determine the most common blood types among the residents and could maintain sufficient supplies in
the local distribution center. Now, that same blood bank is expected to supply all blood types, not just the
common ones. If a local resident with a rare blood type is in a serious car accident, the blood bank either has
to have that blood type stored locally or know where it can be obtained on a moment’s notice.
In today’s competitive environment with high consumer expectation, it is decisions that are based on the most
current data available that improve customer relationships, increase revenue, maximize operational
efficiencies, and even save lives. This technology is real-time business intelligence. Real-time business-
intelligence systems provide the information necessary to strategically improve an enterprise’s processes as
well as to take tactical advantage of events as they occur.
In this white paper, business intelligence is tracked from its early days as a strategic tool to today’s real-time
capabilities for tactically responding to events as they happen. In conclusion, descriptions of the Shadowbase
suite of products from Gravic, Inc. are described, as well as several case studies where the products are
deployed. Shadowbase solutions are available today for achieving real-time business intelligence.
Business Intelligence
As information technology evolved over the years, enterprises automated more and more of their operations.
A great deal of very valuable data resided underutilized in these systems. Data found in sales, accounting,
production, human resources and many other systems could yield significant information to provide historical,
current, and predictive views of business operations. However, this data was often siloed, an “operational
island” that was not readily integratable with other business functions, as were the applications associated with
the data, making leveraging these data and applications across the business very difficult or even impossible
in real-time.
Business intelligence is the consolidation and use of an organization’s disparate data to provide meaningful
information and analyses to employees, customers, suppliers, and partners for more efficient and effective
decision-making. It transforms information into actionable strategies and tactics to: improve the efficiency of
the enterprise, reduce costs, attract and retain customers, improve sales, and provide many other significant
benefits.
Gravic, Inc. White Paper
The Evolution of Real-Time Business Intelligence and How to Achieve it Using Gravic Shadowbase
®
Page 6 of 33
For example, some typical instances of the use of business intelligence include:
The History of Business Intelligence
The Early Days of Computing
Typically, early business applications had their own databases that supported their functions, which became
siloed because no other systems had access to them. These islands of information proliferated as more and
more departments were automated. Mergers and acquisitions compounded the problem since the companies
integrated totally different systems, many of which were doing the same job.
Businesses soon recognized the analytical value of the data that they had available in their many islands of
information. In fact, as businesses automated more systems, more data became available. Collecting this data
for analysis was a challenge due to the incompatibilities between systems because there was no simple way
(and often no way) for these systems to interact. An infrastructure was needed for data exchange, collection
and analysis that could provide a unified view of an enterprise’s data, so the data warehouse evolved to fill this
need.
The Data Warehouse
The data warehouse concept (Figure 1) is a single system for the repository of all of an organization’s data.
This warehouse organizes the information so it can be effectively analyzed and meaningful reports are
prepared for management and other knowledge workers. However, meeting this goal presents several very
significant challenges:
? Data must be acquired from a variety of incompatible systems.
? The same item of information might reside in the databases of different systems in different forms.
A particular data item might not only be represented in different formats, but the values of this data
item might be different in different databases. Which value is the correct (or current) one to use?
? Data is continually changing. How often should the data warehouse be updated to reflect a
reasonably current view?
? The amount of data is massive. How is it analyzed and presented simply so that it is useful?
To meet these needs, a broad range of powerful tools were developed over the years and became productized.
They included:
? Extract, transform, and load (ETL) utilities for the moving of data from the various data sources to
the common data warehouse.
Retail:
Sales Patterns
Integrated Customer View
Campaign Management
Customer Valuation
Analytical CRM
Telecom:
Call-Behavior Analysis
Fraud Detection
Number Portability
Service-Usage Analysis
Promotion Effectiveness
Manufacturing:
Order Life Cycle
Inventory Analysis
Quality Assurance
Supplier Compliance
Distribution Analysis
Financial:
Credit Risk
Monetary Risk
Asset Management
Liability Management
Fraud Detection
Government:
National Security
Crime Analysis
Health
Welfare
Fraud Detection
All Industries:
P & L Analysis
Profitability
Performance Analysis
Value-Chain Analysis
Profiling
Gravic, Inc. White Paper
The Evolution of Real-Time Business Intelligence and How to Achieve it Using Gravic Shadowbase
®
Page 7 of 33
? Data-mining engines for complex predetermined analyses and ad hoc queries of the enterprise
data stored in the data warehouse.
? Reporting tools to provide management and knowledge workers with the results of the analyses
in easy-to-absorb formats; digital dashboards are a predominant example.
Data Warehouse
Ad-Hoc
Queries
Reports
Sales Promotions
Gift Registry
Point-of-Sale
Dashboards
ETL Batch
Transfers
Knowledge Workers
and Management
Offline Extract, Transform, and Load
Early on, the one common interface that was provided between the disparate systems in an organization was
magnetic tape. Tape formats were standardized, and any system could write tapes that could be read by other
systems, and so the first data warehouses were fed by magnetic tapes prepared by the various systems within
the organization. However, that left the problem of data disparity, since the data written by the different systems
reflected their native data organizations. The data written to tape by one system often bore little relation to
similar data written by another system.
Even more important was that the data warehouse’s database was designed to support the analytical functions
required for the business intelligence function. This database design was typically a highly structured database
with complex indices to support online analytical processing (OLAP). Databases configured for OLAP allowed
complex analytical and ad hoc queries with rapid execution time.
The data fed to the data warehouse from the enterprise systems was
converted to a format meaningful to the data warehouse.
To solve the problem of initially loading this data into a data
warehouse, keeping it updated, and resolving discrepancies,
extract, transform, and load (ETL) utilities were developed. As their
name implies, these utilities extract data from source databases, transform them into the common data
warehouse format, and load them into the data warehouse, as shown in Figure 2.
Figure 1 - The Data Warehouse
Gravic, Inc. White Paper
The Evolution of Real-Time Business Intelligence and How to Achieve it Using Gravic Shadowbase
®
Page 8 of 33
The transform function is the key to the success of this approach. Its job is to apply a series of rules to extracted
data so that it is properly formatted for loading into the data warehouse. Examples of transformation rules
include:
? the selection of data to load
? the translation of encoded items (for instance, 1 for male,
2 for female to M, F)
? encoding and standardizing free-form values (New
Jersey, N. Jersey, N. J. to NJ)
? deriving new calculated values (sale price = price -
discount)
? merging data from multiple sources
? summarizing (aggregating) certain rows and columns
? splitting a column into multiple columns (for instance, a
comma-separated list)
? resolving discrepancies between similar data items
? validating the data
? ensuring data consistency
The ETL function allows the consolidation of multiple data sources
into a well-structured database that is used for complex analyses.
The ETL process is executed periodically, such as daily, weekly,
or monthly, depending upon the business needs. This process is
called offline ETL because the target (warehouse) database is not
continuously updated; it is updated on a periodic batch basis.
Though offline ETL serves its purpose well, it has some serious
drawbacks. First, the data in the data warehouse is stale and could
be weeks-old, making it useful for strategic functions but it is not
particularly adaptable to tactical uses. Second, the source
database typically must be quiesced during the extract process,
otherwise, the target database is in an inconsistent state following
the load. As a result, the applications must be shut down, often for
hours, resulting in loss of business services to customers.
In order to evolve to support real-time business intelligence, the ETL function must be continuous and
noninvasive. This function is online ETL, which is described later. In contrast to offline ETL, which provides
stale but consistent responses to queries, online ETL provides current but varying responses to successive
queries since the data that it is using is continually being updated to reflect the current state of the enterprise.
Offline ETL technology has served businesses for decades and the intelligence that is derived from this data
informs long-term reactive strategic decision-making. However, short-term operational and proactive tactical
decision-making continues to rely on intuition, and the business service outage associated with offline ETL is
unacceptable in today’s 24 hour global economy.
Figure 2 - ETL: Extract/Transform/Load
Legacy
System
Database
Warehouse
Database
Intermediate
Database
Extract
Transform
Load
Gravic, Inc. White Paper
The Evolution of Real-Time Business Intelligence and How to Achieve it Using Gravic Shadowbase
®
Page 9 of 33
Data-Mining Engines
The ETL utilities make data collection from many diverse systems practical; however, the captured data needs
to be converted into information and knowledge in order to be useful.
? Data are simply facts, numbers, and text that can be processed by a computer. For instance, a
transaction at a retail point-of-sale is data.
? Information embodies the understanding of a relationship of some sort between data. For example,
analysis of point-of-sale transactions can yield information on consumer buying behavior.
? Knowledge represents a pattern that connects information and generally provides a high level of
predictability as to what is described or what will happen next. An example of knowledge is the
prediction of promotional efforts on sales of particular items based on consumers’ buying behavior.
Powerful data-mining engines were developed to support complex analyses and ad hoc queries on a data
warehouse’s database. Data mining looks for patterns among hundreds of seemingly unrelated fields in a large
database, patterns that identify previously unknown trends. These trends play a critical role in strategic
decision-making because they reveal areas for process improvement and business opportunity. Examples of
data-mining engines are those from SPSS
1
(IBM) and Oracle.
2
Facilities such as these are the foundation for
online analytical processing (OLAP) systems.
Reporting Tools
The knowledge created by a data-mining engine is not very useful unless it is presented clearly and concisely
to those who need it. A common technique for displaying information is the digital dashboard.
3
A digital
dashboard (Figures 3 and 4) provides a business manager with the input necessary to “drive” the business. It
is focused on providing rapid insight into key performance indicators, and consequently is highly graphical with
colored lights, alerts, drill-downs, and gauges.
A digital dashboard provides the user a graphical
high-level view of business processes that can be
drilled-down to see more detail on a particular
business process. This level of detail is often
buried deep in the enterprise’s data, making it
otherwise concealed to a business manager. For
instance, with the digital dashboard shown in
Figure 4, a knowledge worker clicking on an object
will see the detailed statistics for that object.
1
http://www-01.ibm.com/software/analytics/spss/
2
http://www.oracle.com/solutions/business_intelligence/data-mining.html
3
http://en.wikipedia.org/wiki/Dashboards_(management_information_systems)
Figure 3 - Sample Reporting Tool
Gravic, Inc. White Paper
The Evolution of Real-Time Business Intelligence and How to Achieve it Using Gravic Shadowbase
®
Page 10 of 33
Today, many versions of digital dashboards are available from a variety of software vendors. These
dashboards and other sophisticated reporting tools are the collective product of business-intelligence systems.
Driven by information discovered by a data-mining engine, they give the business manager the information
required to:
? see immediately key performance measures
? identify and correct negative trends
? measure efficiencies and inefficiencies
? generate detailed reports showing new trends
? increase revenues
? decrease costs
? make more informed decisions
? align strategies and organizational goals
Data Marts
As corporate-wide data warehouses came into use, it became clear in many cases that a full-blown data
warehouse was overkill for many applications. Data marts evolved to solve this problem and are a specialized
version of a data warehouse. Whereas a data warehouse is a single organizational repository of enterprise-
wide data across all subject areas, a data mart is a subject-oriented repository of data designed to answer
specific questions for a specific set of users. A data mart holds just a subset of the data that a data warehouse
holds.
A data mart includes all of the needs of a data warehouse – ETL, data mining, and reporting. Since a data
mart deals with only a subset of data, it is much smaller and more cost-effective than a full-scale data
warehouse. In addition, because its database is much smaller because it only needs to hold subject-oriented
data rather than all of an enterprise’s data, it is much more responsive to ad hoc queries and other analyses.
Data marts have become popular not only because they are less costly and more responsive but also because
they are under the control of a department or division within the enterprise. Managers have their own local
sources for information and knowledge rather than having to depend on a remote organization controlling the
enterprise data warehouse.
Figure 4 - Sample Digital Dashboard
Gravic, Inc. White Paper
The Evolution of Real-Time Business Intelligence and How to Achieve it Using Gravic Shadowbase
®
Page 11 of 33
Enterprise Application Integration
As data warehouse technology matured, another solution for integrating enterprise-wide data appeared, called
enterprise application integration (EAI). In many cases, the functioning of one enterprise system is significantly
enhanced if it requests data or immediately receives newly generated data from other systems. For instance,
an inventory control system could be much more responsive if it has immediate access to point-of-sale data
so that it could monitor product movement in real-time. A bank could authorize a loan to a customer while the
customer is sitting with the loan officer by analyzing in real-time the customer’s current business with the bank,
his credit worthiness, and the current equity in his assets.
This capability requires that various legacy enterprise systems with different hardware, operating systems, and
databases be enhanced so that they can talk to each other and exchange information in real-time or near real-
time. The deployment of new business services, which were impossible previously, are enabled because the
data and the applications that understood it are isolated from one another.
Intersystem Communication with EAI
EAI provides a means for linking such systems, in some cases without having to make sweeping changes to
existing applications or data structures. In effect, whenever an event occurs in an application, it is sent via a
publish/subscribe (or perhaps broadcast) mechanism to other applications in other systems that may be
interested in this event. Likewise, one system requests data from another system in real-time via a
request/response mechanism. As shown in Figure 5, there are two techniques for implementing EAI, adapters
and message-oriented middleware (MOM), and as shown in Figure 6, there are two techniques of data
replication for implementing EAI. These techniques all perform the transformation of data to a common format
to be used by all systems, the T in ETL.
Adapters
Adapters (Figure 5a) are specialized interfaces between diverse applications and allow those applications to
directly communicate, in a form that is native to each application so major application changes are typically not
required, assuming that the application or adapter vendor has already created/provided the translation and
interface for that application. The adapters perform the necessary translation to a common communications
protocol which is understood by the adapter at each end.
Adapter services must be defined by a common interchange data format to which all systems conform for their
inter-application communication. As a consequence, the use of adapters is often invasive to applications, and
can add inefficiencies to the message path length for the various translations that occur. Each application
involved in communicating with other applications must be modified to use the common data format for the
messages that it sends and receives, or an adapter must be developed to the application’s existing interface.
This problem is aggravated because knowledge is required of the proprietary formats used by the application
vendors, information which many application vendors refuse to divulge. Consequently, adapter services can
often only be implemented by the application vendor or in close cooperation with the application vendor.
4
Also, each application may need to be modified to know how to select events to send, to which systems to
send these events, how to process events it receives from remote applications, and how to respond to requests
from remote applications.
Adapters are highly specialized because each application requires its own adapter that connects to the adapter
network and that translates its application interface and data formats into the common formats of the adapter
network. The range of applications that participates in an EAI network interconnected with adapters is often
limited, and customized or “home grown” applications often do not provide the services necessary to interface.
These problems all served to inhibit the widespread use of adapters for application integration, particularly for
highly customized or “home grown” applications.
4
Of course, some applications either provide an adapter themselves or rely on one of the adapter vendors to create one or more
for them. For example, TIBCO Software, Inc. provides adapter technology for integrating many of the popular application packages.
Gravic, Inc. White Paper
The Evolution of Real-Time Business Intelligence and How to Achieve it Using Gravic Shadowbase
®
Page 12 of 33
Message-Oriented Middleware (MOM)
Message-oriented middleware (MOM) (Figure 5b) provides a mechanism for asynchronously sending
messages between applications. Messages are placed in queues and are sent to their destinations when the
destinations are available. MOM is used to queue messages describing events and to send those messages
to remote applications that take actions based on those events. MOM also provides the messaging facilities to
send requests to other applications and to receive responses to those requests.
5
However, the use of MOM in EAI suffers many of the same problems that adapters face. For one, MOM is
invasive to the application, which can be architected into new applications. However, retrofitting the MOM calls
into an existing application requires access to the application source code, intimate knowledge of the
application processing sequence, and extensive testing of the modified application. As with adapters, MOM
requires that a common data format is established between all systems so that they can understand each
other’s communications. Applications must be modified to conform to this format when they communicate with
other applications. In addition, applications must be modified to know when to send messages and how to
respond to messages from other applications, as well as how to recover/continue processing when the MOM
interface fails or becomes unavailable.
Data Replication
Data replication engines (Figure 6) exchange data between systems
at the database level. This data may take the form of events
generated by one system for consumption by other systems, or it may
take requests from one system to other systems and the responses
to those requests.
The data replication engine can replicate data
from one database to another for each
application to use (Figure 6a). This approach is
particularly useful for isolating target application
processing from interconnection issues as the
receiving database is local to the target
application environment. But auguably a more
powerful approach is shown in Figure 6b where
the database changes in the one database act as
the real-time, event-driven feed into the other
application. In order to interoperate with each
other, applications may be integrated at the
service layer or at the event layer.
With service-level integration, special interfaces
expose server-system data or application
services to external client applications. One way
to accomplish this is via specially designed
agents that reside on the server system. For
instance, a database agent may provide access
to the target database via ODBC, JDBC, OLE,
XML, or ADO.NET.
Event-level integration provides event-driven
integration services based on changes made to
the source system’s database. Event-level
integration avoids the necessity of developing
special agents or adapters for each application
5
MOM interconnects typically provide persistence of the messages being sent and returned, allowing for their asynchronous
nature. Of course, in some cases, these messages are sent synchronously, with the sending application often blocking or waiting
for the reply. In such architectures, loss of the interconnect infrastructure, even temporarily, often means the application itself is
down, or at least severely impacted. This issue can be an important design consideration especially when the interconnect spans
different systems or wide-area communications.
A
d
a
p
t
e
r
A
d
a
p
t
e
r
Point-of-Sale Inventory
Appl Appl
Data
base
Data
base
EAI with Adapters
(a)
Point-of-Sale
Appl Appl
Data
base
Data
base
EAI with MOM
(b)
Inventory
Figure 5 - EAI Intersystem Communication
Gravic, Inc. White Paper
The Evolution of Real-Time Business Intelligence and How to Achieve it Using Gravic Shadowbase
®
Page 13 of 33
that is to be integrated. Rather, it monitors source application events in real-time and sends them immediately
to the target application so that action can be taken on the event by the target.
Notice that this description has used the term “system” rather than “application,” as was used in the descriptions
for adapters and MOM. There is no integration with the data replication engine at the application level. Rather,
replication works at the database level and occurs without any modification to the applications, which are
typically unaware that replication is taking place. The only application modifications necessary are those
required to implement new functions that make use of information from other systems. i.e., to take advantage
of the availability of more information to more applications, enabling the rapid implementation of new business
services.
A replication engine monitors changes to a
system’s database and is driven by a change log
or by database triggers. Based on rules
incorporated into the replication engine, certain
database changes found in the change log are
sent to other systems in the application network.
Alternatively, database triggers can pass critical
changes to the replication engine for
dissemination to other systems. These changes
are either placed in tables in the target systems
(Figure 6) or are otherwise delivered to the
applications via an interprocess message,
MOM, or queue and may be then used by
applications to implement new functionality for
the enterprise.
In addition to the advantage of noninvasiveness
described above, data replication has other
benefits over directly using adapters and MOM.
For one, with adapters or MOM, the
unavailability of the network or another system
brings down the application because it no longer
has access to the data that it needs. With
replication, applications continue to function in
the presence of network failures or external
system outages by using the local copy of the
application database.
Data replication also brings locality to the
application since the application has access to a
local copy of the database. Since it does not reach across the network for data, performance is greatly
enhanced. A common interchange data format is not required when using data replication engines, since the
transferred data must be put into the target tables or target application’s request format according to specified
formatting rules. The transformation of source data to target data is performed by the data replication engine
according to transformation rules specified by the user and incorporated directly into the engine. Applications
access the new data or receive the new requests just as they would access any data or request.
Another advantage of data replication engines is that security is significantly simplified. With adapters and
MOM, every application is an interface and must be secured via encryption. Data replication engines present
only a single interface that must be secured. Not only is the management of security simplified, but the number
of points that may be attacked are also reduced.
Sophisticated data replication technologies (such as the Gravic Shadowbase product portfolio, discussed
further below), also provide mechanisms to not only replicate data between systems, but also to feed database
changes directly to applications by sending events to client applications or servers via queues or client APIs,
publishing data to applications that have subscribed to the data, or responding to poll queries
Point-of-Sale
Appl Appl
Data
base
Data
base
EAI with Data Replication (a)
Point-of-Sale Inventory
Appl Appl
Data
base
Data
base
EAI with Data Replication (b)
Inventory
Replicator
Replicator
Figure 6 - EAI Intersystem Communication
Gravic, Inc. White Paper
The Evolution of Real-Time Business Intelligence and How to Achieve it Using Gravic Shadowbase
®
Page 14 of 33
from client applications. Since data replication avoids the application-specific problems associated with
adapters and MOM, this mechanism has become the technique of choice for EAI.
EAI Networks
EAI networks may either be mesh networks or hub networks. In a mesh network (Figure 7a), every system is
potentially connected to every other system. In a hub network (Figure 7b), all systems communicate via a
central hub that passes data to the target systems.
Sales Promotions Sales Promotions
Gift Registry
Gift Registry
Point-of-Sale
EAI Mesh
Network
(a)
Publish/Subscribe/
Request/Reply
EAI Hub
Network
(b)
Point-of-Sale
Hub
Figure 7 - EAI Networks
A problem with a mesh network is the number of possible connections. If there are n systems in the EAI
network, there can potentially be n(n-1)/2 connections if all systems have to communicate with all other
systems. If a new system is added to the network, n new connections may need to be established, one to each
of the existing systems. This number of connections creates a network complexity that rapidly becomes
unmanageable as the network grows.
A hub network eliminates this problem, as each system is connected only to the hub, which receives messages
from each system and routes each message to the appropriate target systems. A problem with a hub is that it
is a single point of failure, and a hub failure disrupts all functions that require data from other systems. Thus,
all benefits of EAI are lost during a hub failure. Since these messages are functions that are tactical in nature,
governing the real-time response of the enterprise to events as they happen, enterprise operations may be
severely compromised following a hub failure. Consequently, the hub must be made redundant so that it is
highly available.
Another difference between mesh and hub networks is that in a mesh network, every system must know the
data format of every other system. Each system must be able to transform its data format into those of the
other systems. But In a hub network the hub is responsible for data transformation. Each system need only
know the data format expected by the hub.
These issues notwithstanding, a mesh network does have the advantage of avoiding a potential bottleneck at
the hub for information exchange, particularly if the systems are located close to one another but the hub is
remote. If message latency is of paramount importance, or if a hub design can be overwhelmed with request
arrival rate spikes, then a mesh design may be appropriate for at least for some of the connections.
Gravic, Inc. White Paper
The Evolution of Real-Time Business Intelligence and How to Achieve it Using Gravic Shadowbase
®
Page 15 of 33
EAI and Business Intelligence
Using these techniques, EAI allows applications to integrate on a real-time basis as events occur and as
databases are updated without having to wait hours, days or weeks for data from a data warehouse.
Consequently, EAI supports tactical decision-making very well, but it does not provide the historical data
needed for strategic decision-making.
Operational Business Intelligence
Operational business intelligence (OBI) systems provide an intermediate step toward satisfying the strategic
needs that data warehouses address as well as the tactical decision-making that EAI addresses. An OBI
system provides an event database that is frequently updated. As an historical database, the event log
summarizes and satisfies strategic requirements. With frequent updates, strategic decision-making extends to
daily or intra-day information that is used to immediately take operational action to address an immediate
problem.
Colin White, a leading author and consultant in the field of business intelligence, noted that competitive
pressures are forcing companies to react faster to changing business conditions and customer requirements.
Business intelligence (BI) that helps drive and optimize business operations on a daily basis and sometimes
used for intra-day decision-making, is called operational business intelligence. Since the objective of
operational BI is to make more timely business decisions, it has a close relationship to real-time or right-time
BI processing.
Indeed, OBI systems abound today. Conceptually, OBI systems are thought of as a data mart that is updated
frequently (daily, every few hours, or even every few minutes or seconds) with minibatches.
6
OBI systems are
similar to data marts because they generally focus on a specific task rather than on enterprise-wide functions.
For instance, as shown in Figure 8, an OBI system might be periodically fed ATM and point-of-sale (POS)
transactions. Its data-mining engine will then search for potentially fraudulent activity and prepare reports of
such activity. After a review of these reports, a hold might be put on some credit or debit cards until the activity
is resolved.
OBI systems bring together two needs for business intelligence, an historical database for strategic analysis
and the capability to make rapid suggestions for operational actions. But what is still missing is the capability
to make real-time suggestions for actions that are taken immediately upon the occurrence of some specified
event; this capability is real-time business intelligence (RTBI).
Real-time business intelligence is also known as event-driven business intelligence. In order to react in real-
time, a business intelligence system must react to events as they occur, and not minutes or hours later. After
all, if one can use RTBI to stop suspected or fraudulent activity before it completes, enhance a shoppers
online experience, and/or upsell additional products, RTBI has created real, measurable business value for
the organization’s bottom line.
6
A “minibatch” (or “microbatch”) is a collection of data updates (transactions) captured during some prescribed time window, and
trickle-fed to the OBI system to keep it current.
Transaction
Database
Data-Mining
Engine
Operational Business Intelligence System
Hourly/Daily
Minibatches of
Transactions
Suspected
Fraud Report
Figure 8 - A Fraud Detection OBI System
Gravic, Inc. White Paper
The Evolution of Real-Time Business Intelligence and How to Achieve it Using Gravic Shadowbase
®
Page 16 of 33
The following are architectures that allow a business to react proactively in real-time to events as they occur
rather than reactively at some time after they have happened.
Real-Time Business Intelligence
Yesterday’s Data is No Longer Sufficient
Data warehousing solves a strategic need of the enterprise because it manipulates massive amounts of data
via data mining to derive new information and knowledge of an enterprise’s operations. However, data
warehousing has little tactical value since the data in it is generally quite stale and can be days or weeks old.
Data warehousing’s primary value is in supporting strategic goals such as reducing costs, increasing sales,
and improving profits. Even though EAI solves a tactical need of the enterprise since it allows systems to react
immediately to events generated by other systems, it has little strategic value since it provides no repository
of data suitable for data mining.
A solution is needed that satisfies both the strategic and the tactical needs of an enterprise. A store, for
instance, needs to know that men who purchase diapers on Saturday also tend to buy beer at the same time.
A strategic way to capitalize on this information would be to put the beer near the diapers, and have beer sales
on Saturday. A credit card company needs to know that a credit card being used to purchase an item in New
York City was used thirty minutes earlier in Amsterdam. A tactical way to capitalize on this information would
be to deny the transaction, and place a hold on the card.
Another example of the use of real-time business intelligence is in customer support. For instance, a customer
often needs to know if he has enough credit or cash on his credit card or in his debit card account before
attempting to make a purchase. Some card companies allow a customer to get preauthorization for specified
amounts via cell phone to ensure that the purchase is covered, meaning that the card company must have up-
to-date balances for its customers.
Today’s Business Intelligence Needs
The gap between analytical and operational processing is closing fast. Just as Moore’s Law
7
continues to
characterize the rapid pace of technology development, the complex data-mining queries that used to take
hours to run now execute in seconds. If only these data-mining engines had the latest values of the data, the
tactical and strategic needs of business intelligence could be merged into a single solution. There are two
primary impediments to effective and efficient real-time business intelligence: data latency and data
unavailability.
Data latency refers to the staleness of data. The value of data degrades rapidly with its age. When people are
relying on real-time business intelligence to tactically help them with on-the-spot decisions, the freshest data
and the fastest response times are needed.
Data unavailability is a death knell for businesses. If a company’s operations have progressed to the point that
they are dependent on real-time business intelligence, the unavailability of this intelligence due to a failed
system could bring operations to a halt, so extreme availability of the real-time business intelligence services
is paramount.
A business cannot respond to events as they happen if it cannot find out about these events for hours, days,
or weeks (data latency). It also cannot immediately respond to events if the system that supplies the analyses
of these events is down (data availability). If the problems of data latency and data availability are solved,
businesses can react proactively to new information and knowledge rather than reactively. These problems
are solved by sophisticated data replication engines such as Gravic Shadowbase.
7
http://en.wikipedia.org/wiki/moore's_law
Gravic, Inc. White Paper
The Evolution of Real-Time Business Intelligence and How to Achieve it Using Gravic Shadowbase
®
Page 17 of 33
Real-Time Business Intelligence Systems
Even though OBI systems represent a significant improvement in reducing data latency and enabling actions
to be taken within hours of the events that triggered them, they do not meet the criterion of immediacy that will
allow a business to react in real-time to an event. For instance, an OBI system does not generate an offer to a
customer while he is checking out at a cash register. Nor does it deny a potentially fraudulent transaction
before it is executed.
An OBI system is needed that responds to events in seconds or less; but this response is not done by updating
the OBI database with hourly minibatches. Rather, the database must be updated with transaction activity in
real-time as it occurs; this type of update is called trickle-feeding the database. As transactions are received,
they are stored and become a growing historical record of activity.
There must also be a very fast rules engine that analyzes incoming transactions against the historical database
and makes decisions quickly enough so that immediate action of value to the enterprise are taken; this action
is real-time business intelligence (RTBI). There is a distinction between a data-mining engine and a rules
engine. Both require an historical database; but a data-mining engine looks for relationships in the historical
data to reactively support decision-making after the fact. A rules engine compares a real-time event to the
historical data to proactively suggest an action to be taken.
Figure 9 shows the extension of the fraud detection OBI system of Figure 8 to an RTBI system that reacts fast
enough to cause a suspicious transaction denial before it is consummated. In this example, ATM and POS
transactions are fed to the RTBI system as they are generated. The RTBI system posts each transaction to its
database for use by a rules engine that is triggered by the new transaction. In real-time, the rules engine
checks this transaction against recent activity on the credit or debit card and makes an instant determination
of suspicious activity. It then generates a message indicating whether the transaction should be accepted or
denied.
This particular fraud detection example is actually used in real life, as shown in Figure 10. ATM and POS
machines are generally serviced by some particular bank, but the credit or debit card used was probably issued
by some other bank. The card transaction must be sent to the issuing bank for authorization, and verification
that the card balance is sufficient and if so authorizes the transaction.
In this case study, a bank service company operates a transaction switch that receives card transactions from
the servicing banks operating the ATM or POS machines and forwards these transactions to the appropriate
issuing banks. Upon receipt of an accept/deny message from the issuing bank, the transaction switch returns
this message to the servicing bank, which then takes appropriate action to accept or deny the transaction.
Transaction
Database
Rules Engine
Real-Time Business Intelligence System
Real-Time ATM/
POS Transaction
Authorize/
Deny a
Transaction
Figure 9 - A Fraud Detection RTBI System
Gravic, Inc. White Paper
The Evolution of Real-Time Business Intelligence and How to Achieve it Using Gravic Shadowbase
®
Page 18 of 33
Issuing Bank
Transaction
Switch
ATM/POS
Servicing Bank
Fraud Detection
RTBI System
Additionally, the bank service company provides a fraud detection service. At the same time that it forwards
the transaction to the issuing bank for authorization, it also sends the transaction to its RTBI fraud detection
system. If this system determines that the transaction is suspicious, the bank service company takes several
actions as requested by the issuing bank. It certainly denies the transaction and informs the issuing bank, but
it may also alert the issuing bank to the circumstances of the suspicious activity so that it can decide whether
or not to put a hold on the card. This system shows RTBI in action as the RTBI fraud detection system uses
complex rules against an historical database to determine which actions to take that directly affect a transaction
in progress.
RTBI Dashboards
Real-time business intelligence dashboards are used to bridge the gap between operational business
intelligence and real-time business intelligence. For instance, Figure 11 shows an IT server network monitoring
dashboard, which displays not only historical information but also shows the current status of the server
network. The dashboard is interesting because it performs all three business intelligence functions, strategic,
operational, and tactical.
From a strategic viewpoint, it shows bandwidth usage and connection quality over the last several weeks, and
by clicking on the History tab, further historical usage and quality data is displayed. This dashboard forms the
basis for future planning of network upgrades. From an operational viewpoint, the dashboard shows the current
status of the network, the current memory usage, and the current connections and their traffic. If a network
problem occurs, operational staff could immediately take remedial action. From a tactical viewpoint, as
problems are detected, the RTBI system driving the dashboard can issue audible, email, or cell phone alerts
to the operations staff. The RTBI system even takes automatic remedial action such as rerouting network
connections, shedding low-priority traffic, or invoking redundant connections. The transactions are fed to the
new RTBI system from the enterprise’s other systems with the online ETL.
Figure 10 - A Real-Time Business Intelligence Example
Gravic, Inc. White Paper
The Evolution of Real-Time Business Intelligence and How to Achieve it Using Gravic Shadowbase
®
Page 19 of 33
Online ETL
ETL is the facility that allows data to be extracted from a source database, transformed into a common format,
and loaded into a target database (the data warehouse’s database). Since contemporary ETL facilities are
batch-oriented and run periodically, they are characterized as being offline ETL facilities. EAI exchanges
current information between systems in an application network but provides no historical record of enterprise
activity for strategic analysis purposes.
Real-time business intelligence needs an online ETL facility that not only preserves historical strategic data
but can also provide current tactical data. The online ETL’s job is to create and maintain a synchronized copy
of a source database on a target database (the RTBI system) while the source database and the target
database are actively updated and used by multiple applications. In effect, as transactions occur in the
enterprise, they are trickle-fed to the RTBI system in such a way that this activity is transparent to other ongoing
operations. As with EAI, three methods can be used to create an online ETL facility – connecting via adapters,
using message-oriented middleware, and synchronizing via low-latency replication engines.
Adapters
Early adaptations of RTBI used an extension of existing EAI technology. Adapters were used to interconnect
enterprise systems with the RTBI system. As transactions were executed by an external system, the results of
those transactions were communicated to the RTBI system via adapter connections. The adapters also
serviced requests from external systems and returned the RTBI system replies to those systems.
However, adapter technology suffered from the same problems that it faced in EAI applications. It was invasive
and often required application modification in order for the applications to interface with the adapters. In
addition, adapters were specialized to the applications. Each adapter knew the proprietary formats of the
application data structures and how to interface to its application and was thus custom designed for that
application. Every time the application changed, the adapter was modified, so consequently, not all applications
could participate in the online ETL function.
Message-Oriented Middleware
MOM also exhibited many of the same problems that plagued adapters. MOM was invasive and required
changes to the application to send and receive appropriate messages in a common interconnect data format,
or to use adapters. In order to make application changes, access to the application’s source code was required,
but this source code was often lost or was the proprietary property of a third-party vendor, and so was not
available. Additionally, every time the application changed, the MOM code potentially had to be modified. As
with the EAI implementations, adapters and MOM RTBI implementations also suffered from the problems
related to network interconnect issues. Due to the immediate nature of RTBI, if the interconnect went down,
the RTBI response was either delayed, or worse, failed altogether.
Figure 11 - Sample RTBI Dashboard
Gravic, Inc. White Paper
The Evolution of Real-Time Business Intelligence and How to Achieve it Using Gravic Shadowbase
®
Page 20 of 33
Data Replication
Data replication solves the adapter and MOM problems of
application invasiveness and specialization, as well as data
availability, in an RTBI environment. Because a data replication
engine (Figure 12) is noninvasive and is application-unaware, it
deals only with the database, and so is isolated from the application
by the database. Today’s replication engines support most
relational databases and many non-relational databases as well. An additional benefit is that the same data
replication engine,such as Gravic Shadowbase, can also serve other purposes at the same time as fulfilling
the RTBI mission, for example, providing business continuity and disaster recovery.
Data replication is synchronous
(data is replicated to the target
system concurrent with the
application data changes) or
asynchronous (data is
replicated to the target system
some very short time after the
application has made its
changes). In RTBI applications,
asynchronous replication is
generally used, allowing the
replication activity to be totally
transparent to the application.
The application proceeds with
no knowledge of or impact from
the replication activity and the
application’s database activity is extracted by the replication engine via a transaction log, triggers, or intercepts.
Selected updates are sent to the RTBI target system by the replication engine, where they are applied. The
replication latency interval, which is the time that it takes to propagate a source database change to the target
database, is measured generally in sub-seconds.
Replication engines support rules for data transformation. Since some rules are built in, and others are
specified by user-supplied routines, data transformations of any kind are possible without modifying the
applications, the databases, or the core replication engine.
Since replication engines are required to preserve transactional consistency, source updates are not randomly
applied to the target database. Transactions must be applied in the same order to the target database that
they were made at the source database.
An additional problem, called a data collision, occurs when multiple sources simultaneously update their copy
of the same data item. For instance, what happens if two enterprise systems update the same customer
address with different data at the same time? Which one is correct?
Data collisions may happen with any asynchronous mechanism used to feed the RTBI system, whether it is
replication, adapters, or some other form of messaging. Data collisions do not occur if synchronous replication
is used. Most replication engines are particularly adept at handling collisions, detecting and resolving a collision
via specified rules. Some of these rules are built in, and more application-dependent rules are added via user-supplied
routines.
Another problem can occur if a target system fails, and during its downtime, other external applications try to
send it data. If an application does not get a response to its sent data, the application may fail or its data may
be lost. However, replication engines queue this data and will send the data updates to the system when it is
returned to service. As discussed below, in the unlikely event of an RTBI system failure, the replication engines
in each enterprise system queue their data changes and send them to the RTBI system when it is returned to
service, and no valuable business data is lost.
Source
Data
base
RTBI
Data
base
TX Log
Application
Transactions
Replication
Engine
Figure 12 - Data Replication
Gravic, Inc. White Paper
The Evolution of Real-Time Business Intelligence and How to Achieve it Using Gravic Shadowbase
®
Page 21 of 33
A similar problem can occur when a communication connection is lost. With data replication, a system that
loses its connection with an RTBI system continues to operate in so-called split-brain mode. It is unaffected
except that it does not send its data updates to the RTBI system, and it does not receive updates or
recommended actions from the RTBI system. When the connection is restored, all of the updates that
accumulated in either direction are sent to the opposite system via the queues maintained by the replication
engines. In split-brain mode, each system applies updates to its local copy of the data invisibly to the other
system while the connection is down; so there are bound to be data collisions. These collisions are resolved
on-the-fly by the replication engines after recovery of the network and during the resynchronization of the
databases.
Online Copying
Another requirement for online ETL is an online copy utility, which is needed to bring an RTBI system into
operation. An up-to-date snapshot of the data in the various enterprise systems that will feed the RTBI system
must first be loaded into the RTBI system before it becomes effective. This load must occur without affecting
the source systems since they are busy running the enterprise and must include all the various changes that
occur during the copy, which could take hours or even days to complete.
Additionally, the copy must include all of the transformations that were otherwise made by the online ETL
facility in order that the initial RTBI database properly reflects the state of the enterprise. The Shadowbase
SOLV product from Gravic meets all these requirements, and is discussed further below.
Extreme Availability
Once an enterprise activates real-time business information, it would suffer greatly if it lost this capability.
Instant reactions that made it competitive and efficient would be suddenly lost. Extreme availability of the real-
time business information system is of paramount importance.
The first step is to choose an architecture that is especially resilient to failure. NonStop systems from HP are
an ideal solution. These totally redundant systems provide proven availabilities in excess of four 9s (less than
one hour of downtime per year).
8
Clusters of highly reliable industry-standard servers using RAID or mirroring
storage are another choice and are configured to provide availabilities in the same range as HP NonStop
systems, but are much more complex to manage and generally have a higher total cost of ownership (TCO)
9
.
Though these solutions give reasonable protection against single component failures, they do nothing for
disasters that take out an entire data center. The RTBI system must be backed up by a geographically remote
site that takes over in the event of a primary site failure. Otherwise, it might take days or weeks to replace the
system, during which time normal business operations are severely impacted.
Backup systems using magnetic tape to rebuild the database take days to recover and are unsuitable for RTBI
system backup. Virtual tape eliminates some of the problems associated with magnetic tape, but virtual tape
systems still take a prohibitively long time to recover. Data replication to a backup site provides a reasonably
complete copy of the database, but following a primary site failure, the database must still be brought to a state
of consistency, the applications started, the database opened, and the system tested before it is returned to
operation. This strategy takes some time (minutes to hours) and is hindered by the same problem that the
other backup strategies face, questioning whether or not the backup system will properly come up when it is
brought into operation.
8
For a further discussion of 9s as a measure of availability, see The 9s Game, Chapter 1 of Breaking the Availability Barrier:
Survivable Systems for Enterprise Computing, AuthorHouse; 2004.
9
For more information on TCO, see the Gravic article, Why Your Business Continuity Plan May be Inadequate.
Gravic, Inc. White Paper
The Evolution of Real-Time Business Intelligence and How to Achieve it Using Gravic Shadowbase
®
Page 22 of 33
The best “backup” for an RTBI system is an active/active system.
10
An active/active system comprises two or
more geographically-dispersed nodes that are already up and running, with each node actively processing and
sharing the application load with the other nodes. If a node fails, transactions (or users) must be switched from
the failed node to the surviving nodes, a switch that can be done in seconds.
The primary advantages of having an RTBI active backup are twofold. First, failover is accomplished in
seconds. Users of the real-time business information facilities may not even know that a failure has occurred.
Second, the failover process itself does not fail. Since the backup system is already up and running, it is known
that it is fully operational, and its operation is being verified with every transaction it processes.
For some applications or other operational reasons an active/active RTBI configuration may not be possible.
An alternative which may be used in such cases is known as sizzling-hot-standby. The only difference between
this alternative and an active/active configuration is that the standby system is not actually processing
transactions, in all other respects it is identical, and shares all the advantages of an active/active system.
As previously stated, there are two impediments to real-time business intelligence, data latency and data
unavailability. Online ETL (and especially data replication) solves the problem of data latency. Active/active or
sizzling-hot-standby RTBI systems solve the problem of data unavailability.
The Operational Data Store – The Next Evolutionary Step?
What is an Operational Data Store?
In the early 2000s, the Gartner Group coined the term zero latency enterprise (ZLE). In its words, ZLE was
“the instantaneous awareness and appropriate response to events across an entire enterprise.” This response
was later renamed the real-time enterprise (RTE).
HP was a leader in ZLE, with its ZLE architecture centered around an operational data store (ODS) that was
similar to the data store used by a data warehouse. Rather than periodically loading the ODS with massive
amounts of data via an ETL facility, the ODS was trickle-fed transactions as they occurred so that it always
contained the latest state of the enterprise as well as historical information (Figure 13). Using the ODS,
classical data-mining engines could generate strategic information and knowledge, and real-time rules engines
could make tactical decisions regarding immediate actions to take.
One particular ODS characteristic requires it to handle mixed workloads. On the one hand, it must be able to
respond to complex queries from knowledge users, data-mining facilities, and rules engines using online
analytical processing (OLAP). The database structures suitable for OLAP are characterized by fat keys that
allow rapid searching of the database to respond to complex queries. On the other hand, the ODS must be
capable of online transaction processing (OLTP) at an extremely high transaction rate, as it is being fed
transactions in real-time from many enterprise systems. The database structures suitable for OLTP are
characterized by skinny keys that require a minimum of updating as data is added to the database.
Another particular ODS characteristic is that it is bi-directional. Unlike a data warehouse, which only accepts
information from enterprise systems, an ODS both accepts information from and delivers information to the
other enterprise systems. An example of this characteristic is the act of keeping databases in synchronization.
A particular data item, like a customer’s address, may be stored in several databases around the enterprise. If
one system changes this data item, the ODS acts as a central data repository that informs the other systems
of the new data value so they update their databases.
For more information on active/active systems, see the Gravic white paper, Achieving Century Uptimes with Shadowbase
Active/Active Technology.
Gravic, Inc. White Paper
The Evolution of Real-Time Business Intelligence and How to Achieve it Using Gravic Shadowbase
®
Page 23 of 33
Operational Data Store (ODS)
Replication
Dashboards
Strategic Applications
Tactical
Rules-Based
Applications
Ad-Hoc
Queries
Reports
Gift Registry
Point-of-Sale
Rules Engine
Sales Promotions
Another example of outgoing information are the results of the rules engine. If the rules engine decides to
recommend a particular immediate action, that action is communicated to the appropriate enterprise system
for execution. For instance, if the rules engine for a credit card processor detects suspicious activity, it
immediately alerts the authorization system to take appropriate action.
In concept, the ODS, which contains all of a corporation’s data, could become the database of record, the
single version of truth. This action generally does not happen because of regulatory requirements and other
considerations and the database of record remains on the existing systems, where it was resident for decades.
The Evolution of RTBI to ODS
As previously described, the ODS is simply the RTBI system but extended to the enterprise. Though RTBI
systems are becoming common today, full-blown ODS systems have yet to make a significant appearance
due to the complexity and cost of designing and building such far-reaching systems.
It is conceivable that RTBI systems may evolve eventually to ODS systems, as shown in Figure 14. Early
dedicated business intelligence systems used data warehouse or EAI technologies. As these technologies
proved their worth, data replication was added to move the technologies to real-time business intelligence
systems, thus expanding their reach. Though RTBI systems exist today in many applications, each RTBI
system generally supports a single purpose such as fraud detection, instant customer promotions, or just-in-
time inventory.
Considerable effort was invested by some companies to consolidate a multitude of RTBI systems into a single
ODS supporting enterprise-wide tactical and strategic decision-making, shown as the final step in Figure 14.
The cost and disruption imposed by conversion to an ODS has so far resulted in little progress in expanding
RTBI systems to support both tactical and strategic decision-making for any particular corporate function, much
less the enterprise. The advantages of such integration are clear:
? The single ODS supports both tactical and strategic decision-making.
? The ODS is made highly available through redundancy, such as using an active/active system to
achieve not only high availability of the system, but also to achieve disaster tolerance. Corporate
functions are less affected by the failure of one of the other systems. For example, a customer’s credit
status is checked against the ODS without having to interrogate a credit-authorization system that
might be down.
Figure 13 - The Operational Data Store
Gravic, Inc. White Paper
The Evolution of Real-Time Business Intelligence and How to Achieve it Using Gravic Shadowbase
®
Page 24 of 33
? The scope of decision-making is extended to many more areas across the enterprise. For instance, a
drop in sales is correlated with increased accounts receivables on store-branded credit cards. Easier
credit terms might help to restore sales to their previous level.
? The various corporate IT systems are isolated. No longer do they have to interact with each other
through EAI. They each communicate only with the ODS system. Newly added applications do not
have to be configured to interface with multiple other applications and only need to interface with the
ODS. Also, other systems do not have to be modified to interface with the new system.
The obstacles to achieving this goal have been daunting so far. For instance:
? The ODS is an expensive system in terms of hardware acquisition, software licensing, and
development.
? More powerful data-mining engines and rules engines may need to be incorporated.
? The design of the ODS database is much different and needs to support both tactical and strategic
queries, yet be very efficient in handling a large volume of updates. Fast update processing requires
? skinny keys in which a minimum of alternate indices must be updated, while efficient query processing
requires fat keys providing many access paths to the data.
? The size and depth of the ODS can be quite extensive, as it typically has to store large volumes of
historical and archival versions of the data, instead of just the current value of the data (also referred
to as managing long data issues).
? Current database products tend to handle structured data well, but corporations also want to leverage
their unstructured data (e.g., video, email, voice, text) for business gain. So-called big data collection,
indexing, and accessing issues tend to thwart co-locating all of this information into a
Real-Time
Business
Intelligence
Real-Time
Business
Intelligence
BI
data
base
BI
data
base
Real-Time
Enterprise
Data
Warehouse
DW
Data
base
Real-Time
Data Marts
DM
Data
base
BI
data
base
Business
Intelligence
Business
Intelligence
BI
data
base
Batch Updates
Data Marts
Enterprise
Data
Warehouse
DW
data
base
DM
data
base
Batch Updates
Real-Time Updates Real-Time Updates
DATA CONSOLIDATION
E
v
o
l
u
t
i
o
n
o
f
B
u
s
i
n
e
s
s
I
n
t
e
l
l
i
g
e
n
c
e
TACTICAL STRATEGIC
operational data
store
tactical/strategic
Real-Time
Business
Intelligence
Real-Time
Enterprise
Data Warehouse
Real-Time
Data Marts
Real-Time Updates
C
o
n
s
o
l
i
d
a
t
i
o
n
o
f
B
u
s
i
n
e
s
s
I
n
t
e
l
l
i
g
e
n
c
e
Figure 14 - The Evolution of the Operational Data Store
Gravic, Inc. White Paper
The Evolution of Real-Time Business Intelligence and How to Achieve it Using Gravic Shadowbase
®
Page 25 of 33
single repository, managed by a single DBMS. The volume of data generation overwhelms typical
storage capacities. Clearly, more powerful data collection, transmission, storage and retrieval systems
are needed.
? Applications may have to be significantly rearchitected, which is not only expensive and time
consuming, but risky.
? Third-party products that do not readily lend themselves to adapting to an ODS architecture may be
involved.
? The conversion of current decision-making processes might not only be difficult but may, in fact, be
resisted by the user community.
The bottom line is that today, companies are achieving RTBI by directly integrating their systems using real-
time data replication, or they are trickle-feeding data marts in real-time and using these to gather information.
These warehouses or application networks may or may not turn into an ODS as consolidation occurs. If no
warehouse currently exists to act as the stepping stone to an ODS, companies may find it more economical to
simply interconnect their systems in a mesh network using existing EAI technologies, instead of following a
more planned, fruitful, but expensive path to an ODS.
Real-Time Business Intelligence Solutions from Gravic
This paper has laid out the evolution of RTBI, and the various technologies that over the years have been used
to achieve it. It has demonstrated that of these technologies, data replication is by far the most flexible, least
disruptive, and easiest to implement. The Shadowbase suite of products, from Gravic, Inc.
(www.gravic.com/shadowbase), provides the replication and online copying facilities needed for effective real-
time business intelliigence systems. These products also provide the infrastructure to implement extreme
availability architectures and include Shadowbase, a real-time data replication engine, and SOLV, a powerful
online copy utility.
Shadowbase Software – Real-Time Replication
The Shadowbase data replication engine provides high-speed data replication among a variety of databases
and platforms. With a history in the decades and hundreds of large, mission-critical, enterprise-class
installations worldwide, the Shadowbase engine is a proven performer and is an ideal solution for
interconnecting enterprise systems with an RTBI system. Shadowbase software:
? provides uni- and bi-directional asynchronous data replication, supporting active/passive, sizzling-
hot-standby, and active/active system configurations. Shadowbase synchronous data replication
is under development. (Contact Gravic for more information.)
? is totally transparent to the applications. It requires no application modifications because it gets
database changes from a transaction log or from database triggers or intercept libraries.
? runs on a wide variety of platforms against several databases; source platforms include HP
NonStop, Linux, Unix, and Windows. Target platforms include all source platforms plus
OpenVMS and AS400. Shadowbase replicates from NonStop SQL, Enscribe, Oracle, Sybase, and
SQL Server databases to these same databases as well as to DB2 and MySQL database, and
can also replicate to any ODBC-compliant target database. (See www.gravic.com/shadowbase for
the current list of supported databases.)
? has no disk-queuing points, so replication is very rapid. Replication latency is measured in the tens
of milliseconds on many systems and performance is enhanced by its multithreading capability.
? runs as checkpointed process pairs and persistent processes on HP NonStop systems so that it
survives hardware and software failures. On other systems, its processes run as persistent
processes under a monitor.
Gravic, Inc. White Paper
The Evolution of Real-Time Business Intelligence and How to Achieve it Using Gravic Shadowbase
®
Page 26 of 33
? guarantees the integrity and consistency of the target database even when running with multiple
threads. Alternatively, it is configured to break source transactions into subtractions to enhance
replay parallelism and performance.
? has extensive built-in data transformation rules that are augmented by user-supplied specialized
rules.
? provides complete data collision detection and resolution facilities for active/active environments.
Users extend its collision resolution rules with additional business rules tailored to their
application’s business logic.
? is heterogeneous; any supported platform and any supported database may serve as a source
system or as a target system in any mix.
? is easy to manage with its AUDMON process monitor, its AUDCOM command interface, and its
Shadowbase Enterprise Manager (SEM), a Windows GUI that provides integrated command and
monitoring support for its components running in a heterogeneous environment.
Extreme Availability with Shadowbase Active/Active Support
Many Shadowbase installations around the world are active/active, geographically distributed systems. These
systems achieve availabilities in excess of six 9s (less than thirty seconds per year of downtime). Shadowbase
replication provides two functions in an RTBI environment: it synchronizes the operational systems with the
RTBI system and synchronizes multiple RTBI systems in a redundant active/active or sizzling-hot-standby
configuration.
Running an RTBI system as an active/active system simply requires that the Shadowbase engine replicates
database changes between the two geographically separated RTBI systems. If one system fails, the other
system is immediately ready to take over the real-time business intelligence services. With an active/active
RTBI system, it is fair to say that the uptime of real-time business intelligence services is measured in centuries.
Shadowbase SOLV – Online Copying
The critical online copying function needed to bring an RTBI system
into service is provided by the unique copying utility, Shadowbase
Online Loading (SOLV), which:
? moves data from a source database to the target
database without interrupting source database activity.
? maintains target data that was already copied in a current state by applying changes to it as other
portions of the source database are copied. There is no large queue of source database changes
that needs to be applied following the copy.
? maintains currency of those parts of the database that were already copied, which may then be
used by applications at the target system while the copy is in progress.
Another powerful feature of SOLV is inherent in its architecture. Since SOLV is not a utility separate from the
Shadowbase replication engine, it uses the Shadowbase replicator to move data from the source database to
the target database. As a consequence, SOLV uses the same data transformation rules during the copy
function that the Shadowbase engine uses during later data replication. This function avoids the problem of
trying to conform the copy transformation rules with the replicator transformation rules so that both perform
exactly the same. Rules are implemented only once because the same code is then used by both the load
engine and the replication engine.
Gravic, Inc. White Paper
The Evolution of Real-Time Business Intelligence and How to Achieve it Using Gravic Shadowbase
®
Page 27 of 33
Shadowbase Streams
Shadowbase Streams, another member of the Shadowbase
product line, streams data generated by one application to other
applications and facilities as well as target database environments.
Shadowbase Streams for Data Integration and Application
Integration provides the facilities for integrating existing applications
at the data or event-driven level in order to create new and powerful
functionality for the enterprise. Shadowbase Streams:
? quickly and easily integrates changes made in any database into other data environments to keep
that target information synchronized. The changes can be made in real-time or batched for periodic
snap-shot or micro-batch updating.
? interoperates applications that were once isolated in an event-driven fashion in real-time. Critical
data generated by one application is distributed and acted upon immediately by other applications.
? supports many models for data distribution, including maintaining a remote database of critical
data, sending critical data to client applications or servers directly via queues or client APIs,
publishing data to applications that have subscribed to the data, and responding to poll queries
from client applications.
? is extensible, allowing the user to embed custom processing logic into the data processing path.
It readily filters, transforms, and adapts data from one application or database environment into
the format or protocol required by another application or database environment, all without
requiring any changes to the existing application that is generating the data.
? modernizes legacy applications by integrating diverse applications across the enterprise so that
new and valuable services are generated to enhance competitiveness, to reduce costs or to
increase revenue, to satisfy regulatory requirements, and to generally improve the user
experience.
? plays a significant role in the distribution of data from disparate sources throughout the enterprise
in real-time, thereby facilitating the implementation of RTBI capabilities.
11
.
Shadowbase Real-Time Business Intelligence Case Studies
Shadowbase solutions are used extensively to provide real-time business intelligence to a variety of
enterprises. Some examples of these applications and how it is being used to improve business services,
company competitiveness, and profitability are shown in the case studies below.
Fraud Detection
ATM and point-of-sale (POS) devices are typically managed by a local servicing bank. However, this bank is
likely not the bank that issued the credit or debit card used at the device. A major provider of interbank
electronic transaction switching services for ATM and POS terminals routes each credit card transaction from
the servicing bank to the bank that issued the credit card. The issuing bank then returns an authorization or a
rejection to the credit card terminal via the provider’s switching system and the servicing bank.
If the transaction switch fails, no credit card transactions are accepted by the terminals that the transaction
switch provider services. The provider uses an active/active, geographically distributed system comprising HP
NonStop nodes to provide extreme reliability for its transaction message switch (Figure 15). Shadowbase bi-
directional replication is used to keep the databases of the active/active nodes in synchronization.
For more information, please see the Gravic white papers, Shadowbase Streams for Data Integration and Shadowbase Streams
for Application Integration.
Gravic, Inc. White Paper
The Evolution of Real-Time Business Intelligence and How to Achieve it Using Gravic Shadowbase
®
Page 28 of 33
As an additional service to the credit card companies that are its customers, the provider offers fraud detection.
Credit card transactions captured by its HP NonStop servers use the Shadowbase data replication engine on
a Solaris server running Oracle. The credit card transactions are transformed by Shadowbase replication to
the format required by the Oracle database. Complex queries are run against the Oracle database to monitor
card activity for suspected fraudulent activities.
If a suspected fraudulent transaction is detected, an indication of this transaction is immediately returned via
Shadowbase replication to the HP NonStop switch for forwarding to the issuing bank. The issuing bank can
elect to reject the transaction and deactivate the card or to allow the transaction.
This case study is an excellent example of real-time business intelligence at work. The Solaris system is an
RTBI system and maintains a history of credit card usage for each credit card and uses the current credit card
transaction data to deduce the possibility of fraud. If fraud is suspected, this suspicion is communicated in real-
time to the issuing bank for immediate action, potentially saving the company thousands of dollars in fraudulent
transactions.
Investment Product Promotion
A provider of stock trade execution services provides real-time business intelligence systems to its brokerage
customers. The brokerages use this RTBI system to monitor the trading activity of their individual customers
to determine possible investment products in which their customers might be interested.
The execution service provider uses an HP NonStop system to execute trades submitted to it by its brokerage
customers (Figure 16). It sends customer trade requests to the appropriate exchange floor for execution and
returns execution reports to the brokerage firm. Connections between the brokerage firm system and the
execution system are provided by the Shadowbase data replication engine.
Shadowbase
S
h
a
d
o
w
b
a
s
e
S
h
a
d
o
w
b
a
s
e
RTBI ATM
Fraud Detection
Solaris Oracle
NonStop NonStop
Active/Active
Transaction Switch
Issuing
Banks
Servicing
Bank
Servicing
Bank
ATM POS
Figure 15 - Real-Time Business Intelligence for Fraud Detection
Gravic, Inc. White Paper
The Evolution of Real-Time Business Intelligence and How to Achieve it Using Gravic Shadowbase
®
Page 29 of 33
The execution service provider supplies a back office system to its brokerage firms to handle trade accounting
and position management. This system also has an RTBI component for monitoring customer activity.
Individual customers enter their trade requests via the Internet into the brokerage firm’s back office accounting
system. Each trade request is forwarded to the execution service provider for execution. The execution report
is returned to the customer by the brokerage firm and is used to update the customer’s position and trading
activity in the back office accounting system.
The RTBI subsystem resident in the back office system continually monitors the customer’s portfolio position
and trading activity. It analyzes the risk tolerance exhibited by the customer through his activity and, along with
the customer’s age and other information, determines if investment products provided by the brokerage firm
might be of interest to the customer. If so, information on those products is sent to the customer while he is
online. This case study is an example of an RTBI system using real-time events to determine potential
marketing opportunities, thereby increasing revenues.
Tactical Reordering and Strategic Marketing
A major North American independent distributor represents more than three million parts critical to the
operations of maintenance, repair, and overhaul (MRO) and original equipment manufacturer (OEM)
customers in virtually every industry. It also provides engineering, design, and systems integration for industrial
and fluid-power applications as well as customized mechanical, fabricated rubber and fluid-power shop
services.
S
h
a
d
o
w
b
a
s
e
S
h
a
d
o
w
b
a
s
e
Internet
Exchange
Floor
Trade
Executions
NonStop
Execution System
RTBI functions
Age
Portfolio Position
Trade Activity
Risk Tolerance
Back-Office
Accounting System
Customer
Trading Activity
Investment Product
Promotions
Trades Executions
Figure 16 - Investment Product Promotion
Gravic, Inc. White Paper
The Evolution of Real-Time Business Intelligence and How to Achieve it Using Gravic Shadowbase
®
Page 30 of 33
Its network encompasses more than 4,600 associates at 445 facilities in the continental United States, five
Canadian provinces, Puerto Rico, and Mexico. Its seven strategically located distribution centers warehouse
millions of dollars of inventory to support its local service centers and customers with necessary products. The
distributor uses an HP NonStop server to accept orders from its customers and to fulfill these orders (Figure
17).
To better improve operations, the distributor implemented a real-time business intelligence system running
under Windows SQL Server. This system is driven by order information from the HP NonStop order-entry
system delivered via a Shadowbase data replication engine. The RTBI system maintains a database of order
history and current orders.
Using the order history and analytic strategic processing, the distributor determines what marketing services
will be the most effective to grow its business (a strategic data warehouse function). Using current order activity,
it determines in real-time when parts need to be reordered (a tactical RTBI function). This case study is an
example of feeding an RTBI system that supports both strategic analytics and tactical responses to current
events in order to increase revenues and improve customer satisfaction.
Travel Analysis and Profiling
One of Europe’s leading providers of tours and packaged travel offers an expansive array of flights, hotels,
package tours, flexi-packages and independent holidays to travel agencies and several million consumers
throughout Europe. Its travel brand offers flexible and fixed vacation packages to major leisure destinations
worldwide. It supports hundreds of travel agents with an HP NonStop server system.
One of the provider’s services is to offer discount coupons to its clients for frequently traveled routes and
destinations. To determine the applicability of coupons for various itineraries, it uses a real-time business
intelligence system to track travel patterns and volumes.
This business intelligence system runs on a Windows SQL Server (Figure 18) and uses online analytical
processing to discover travel patterns of potential candidates for coupons. Travel data from its HP NonStop
server is sent in real-time via the Shadowbase data replication engine to the business-intelligence system as
the provider’s travel agents book travel and accommodations for their clients. Using this architecture, the
company determines in near real-time appropriate travel patterns, and then offers timely travel and leisure
discount coupons to its clientele, for increasing revenue generation.
Windows SQL Server
Marketing Services
Shadowbase
NonStop Server
Order Entry
RTBI Current Order Database Order Processing
Trickle Feed
Strategic
Analysis
RTBI
Reorder
Figure 17 - Real-Time Business Intelligence for Parts Distribution
Gravic, Inc. White Paper
The Evolution of Real-Time Business Intelligence and How to Achieve it Using Gravic Shadowbase
®
Page 31 of 33
Summary
The speed of today’s processing systems has moved classical data warehousing into the realm of real-time.
The result is real-time business intelligence. Business transactions as they occur are fed to a real-time
business intelligence system that maintains the current state of the enterprise. The RTBI system not only
supports the classic strategic functions of data warehousing for deriving information and knowledge from past
enterprise activity, but also provides real-time tactical support to drive enterprise actions that react immediately
to events as they occur. It replaces both the classic data warehouse and the enterprise application integration
functions. Such event-driven processing is a basic tenet of real-time business intelligence.
The Shadowbase suite of products provides the capabilities necessary to integrate disparate operational
application information into the RTBI system and to support the functions of real-time business intelligence.
The Shadowbase replication engine is a high-speed, bi-directional, heterogeneous data replication engine that
moves data updates from enterprise systems to the RTBI system and back in fractions of a second. It allows
the events to be filtered and transformed into formats that downstream processing can utilize, allowing for
embedding complex processing rules into the replication engine instead of having to encode them into the
applications themselves. It supports active/active configurations for RTBI systems to achieve extreme
availability.
With real-time business intelligence, an enterprise establishes long-term strategies to optimize its operations
while at the same time reacting with intelligence to events as they occur. Shadowbase software provides
companies the suite of products necessary to leverage this RTBI technology with proven implementations,
while providing significant business benefits.
Windows SQL Server
Client Services
Shadowbase
NonStop Server
Reservations
Agents
Travel Data
RTBI Coupon Travel
Pattern Analysis
Figure 18 - Real-Time Business Intelligence for Travel Packaging
The Evolution of Real-Time Business Intelligence and How to Achieve it Using Gravic Shadowbase
®
Gravic, Inc. White Paper Page 28 of 33
Gravic, Inc. Contact Information
17 General Warren Blvd.
Malvern, PA 19355-1245
USA
Tel: +1.610.647.6250
Fax: +1.610.647.7958
www.gravic.com/shadowbase
Email Sales: [email protected]
Email Support: [email protected]
International Distributor Information
Global
Hewlett-Packard NonStop Enterprise Division
1501 Page Mill Road #1429
Palo Alto, CA 94304-1100
USA
Tel: +1.408.691.2908
www.hp.com
Europe
Hewlett-Packard Nederland BV
Startbaan 16
Amstelveen 1187 XR
The Netherlands
Tel: +31 20 547 6911
Fax: +31 20 547 7755
www.hp.nl
Africa
Business Connexion (Pty) Ltd
Business Connexion Park
789 16th Road
Randjiespark
Midrand
South Africa
Tel: +27 (0)11 653 5365
www.bcx.co.za
Asia Pacific
Legato Solutions & Services Pte Ltd
10 Ubi Crescent
#04-65 Ubi TechPark
Singapore 408564
Tel: +65 68463 150
Fax: +65 67489 356
www.legato.com.sg
Japan
High Availability Systems Co. Ltd
MS Shibaura Bldg.
4-13-23 Shibaura
Minato-ku, Tokyo 108-0023
Japan
Tel: +81 3 5730 8870
Fax: +81 3 5730 8629
www.ha-sys.co.jp
Gravic, Inc. White Paper
The Evolution of Real-Time Business Intelligence and How to Achieve it Using Gravic Shadowbase
®
Page 29 of 33
Breaking the Availability Barrier Book Series
Breaking the Availability Barrier, Survivable Systems for Enterprise Computing
Volume I describes the techniques that can be used today for extending the time
between system failures from years to centuries, often at little or no additional cost.
For More Information.
Breaking the Availability Barrier, Volume II, Achieving Century Uptimes with
Active/Active Systems
Volume II extends the theoretical topics covered in Volume I and covers significant
issues and technologies related to active/active architectures, including availability
calculations, redundant reliable networks, distributed databases, TCO, and node
failures.
For More Information.
Breaking the Availability Barrier, Volume III, Active/Active Systems in Practice
Volume III is a companion to Volume II and contains practical examples and case studies
for actually building active/active systems based upon the principles covered in Volumes
I and II.
For more information.
The authors of this series, Dr. Bill Highleyman, Paul J. Holenstein, and Dr. Bruce D. Holenstein, have a
combined experience of over 100 years in the implementation of fault-tolerant, highly available computing
systems. This experience ranges from the early days of custom redundant systems to today’s fault-tolerant
offerings from HP (NonStop) and Stratus. Learn more about the authors. These books can be ordered from
www.authorhouse.com or www.amazon.com. For white papers, case studies, datasheets, and more
information, please visit www.gravic.com/shadowbase/whitepapers.
For further information about Shadowbase solutions and how they enable active/active replication
architectures or are used to solve other business problems, such as feeding a data warehouse with real-time
data, contact Gravic at +1.610.647.6250, [email protected], or visit our website at
www.gravic.com/shadowbase.
About Gravic, Inc.
Gravic, Inc. is a privately-held corporation located in Malvern, PA, about twenty miles west of Philadelphia, PA, USA. Gravic makes a
number of computer software products for data collection, transformation, and distribution uses. Customers of its Shadowbase data
replication and data integration products include banks, financial and brokerage firms, insurance companies, stock exchanges, electric
utilities, healthcare, and telecommunications companies.
Copyright and Trademark Information
This document is Copyright © 2014 by Gravic, Inc. Gravic, Shadowbase and Total Replication Solutions are registered trademarks of
Gravic, Inc. All other brand and product names are the trademarks or registered trademarks of their respective owners. Specifications
subject to change without notice.
doc_621830239.pdf
The speed of todays processing systems has moved classical data warehousing into the realm of real-time.
Gravic, Inc. White Paper
The Evolution of Real-Time Business Intelligence
and How To Achieve It Using Gravic Shadowbase
®
A Gravic, Inc. White Paper
The Evolution of Real-Time Business Intelligence and How to Achieve it Using Gravic Shadowbase
®
Gravic, Inc. White Paper Page 2 of 33
Executive Summary
In today’s competitive environment with high consumer expectation, business
decisions based on the most current data available to the enterprise are the
ones that will improve customer relationships, increase revenue, and
maximize operational efficiencies.
The speed of today’s processing systems has moved classical data
warehousing into the realm of real-time. The result is real-time business
intelligence (RTBI). Business transactions are fed as they occur to a real-time
business-intelligence system that maintains the current state of the enterprise.
The RTBI system not only supports the classical strategic functions of data warehousing for deriving
information and knowledge from past enterprise activity, but it also provides real-time tactical support to
drive enterprise actions that react to immediate events. As such, it replaces both the classical data
warehouse and the enterprise application integration (EAI) functions. An RTBI system with a consolidated
real-time view of the business across the enterprise enables the provision of new business services
(applications) which were previously impossible, achieving competitive advantage.
Real-time business intelligence is also known as event-driven business intelligence. In order to react in
real-time, a business intelligence system must react to events as they occur – not minutes or hours later.
With real-time business intelligence, an enterprise can establish long-term strategies to optimize its
operations and maximize competitiveness while at the same time reacting with intelligence to events as
they occur.
In this white paper, business intelligence is tracked from its early days as a strategic tool to today’s real-
time capabilities for tactically responding to events as they happen. In conclusion, descriptions of the
Shadowbase suite of products from Gravic, Inc. are described, as well as several case studies where the
products are deployed. Shadowbase solutions are available today for achieving real-time business
intelligence.
The Evolution of Real-Time Business Intelligence and How to Achieve it Using Gravic Shadowbase
®
Gravic, Inc. White Paper Page 3 of 33
Table of Contents
Business Intelligence .............................................................................................................................. 5
The History of Business Intelligence ...................................................................................................... 6
The Early Days of Computing ............................................................................................................. 6
The Data Warehouse .......................................................................................................................... 6
Offline Extract, Transform, and Load .................................................................................................. 7
Data-Mining Engines ........................................................................................................................... 9
Reporting Tools ................................................................................................................................... 9
Data Marts ......................................................................................................................................... 10
Enterprise Application Integration ......................................................................................................... 11
Intersystem Communication with EAI ............................................................................................... 11
Adapters ........................................................................................................................................ 11
Message-Oriented Middleware (MOM) ......................................................................................... 12
Data Replication ............................................................................................................................ 12
EAI Networks .................................................................................................................................... 14
EAI and Business Intelligence .......................................................................................................... 15
Operational Business Intelligence ........................................................................................................ 15
Real-Time Business Intelligence .......................................................................................................... 16
Yesterday’s Data is No Longer Sufficient ......................................................................................... 16
Today’s Business Intelligence Needs ............................................................................................... 16
Real-Time Business Intelligence Systems ........................................................................................ 17
RTBI Dashboards.............................................................................................................................. 18
Online ETL ........................................................................................................................................ 19
Adapters ........................................................................................................................................ 19
Message-Oriented Middleware ..................................................................................................... 19
Data Replication ............................................................................................................................ 20
Online Copying.................................................................................................................................. 21
Extreme Availability ........................................................................................................................... 21
The Operational Data Store – The Next Evolutionary Step? ............................................................... 22
What is an Operational Data Store? ................................................................................................. 22
The Evolution of RTBI to ODS .......................................................................................................... 23
Real-Time Business Intelligence Solutions from Gravic....................................................................... 25
Shadowbase Software – Real-Time Replication .............................................................................. 25
Extreme Availability with Shadowbase Active/Active Support .......................................................... 26
Shadowbase SOLV – Online Copying .............................................................................................. 26
Shadowbase Streams ....................................................................................................................... 27
Shadowbase Real-Time Business Intelligence Case Studies .............................................................. 27
Fraud Detection................................................................................................................................. 27
Investment Product Promotion .......................................................................................................... 28
Tactical Reordering and Strategic Marketing .................................................................................... 29
Travel Analysis and Profiling ............................................................................................................. 30
Summary .............................................................................................................................................. 31
Gravic, Inc. Contact Information ........................................................................................................... 28
International Distributor Information ..................................................................................................... 28
Breaking the Availability Barrier Book Series ....................................................................................... 29
About Gravic, Inc. ................................................................................................................................. 29
Gravic, Inc. White Paper
The Evolution of Real-Time Business Intelligence and How to Achieve it Using Gravic Shadowbase
®
Page 4 of 33
Table of Figures
Figure 1 - The Data Warehouse ................................................................................................................... 7
Figure 2 - ETL: Extract/Transform/Load....................................................................................................... 8
Figure 3 - Sample Reporting Tool ................................................................................................................ 9
Figure 4 - Sample Digital Dashboard ......................................................................................................... 10
Figure 5 - EAI Intersystem Communication ............................................................................................... 12
Figure 6 - EAI Intersystem Communication ............................................................................................... 13
Figure 7 - EAI Networks ............................................................................................................................. 14
Figure 8 - A Fraud Detection OBI System ................................................................................................. 15
Figure 9 - A Fraud Detection RTBI System ............................................................................................... 17
Figure 10 - A Real-Time Business Intelligence Example ........................................................................... 18
Figure 11 - Sample RTBI Dashboard ......................................................................................................... 19
Figure 12 - Data Replication ...................................................................................................................... 20
Figure 13 - The Operational Data Store ..................................................................................................... 23
Figure 14 - The Evolution of the Operational Data Store ........................................................................... 24
Figure 15 - Real-Time Business Intelligence for Fraud Detection ............................................................. 28
Figure 16 - Investment Product Promotion ................................................................................................ 29
Figure 17 - Real-Time Business Intelligence for Parts Distribution ........................................................... 30
Figure 18 - Real-Time Business Intelligence for Travel Packaging ........................................................... 31
Gravic, Inc. White Paper
The Evolution of Real-Time Business Intelligence and How to Achieve it Using Gravic Shadowbase
®
Page 5 of 33
The Evolution of Real-Time Business Intelligence
and How to Achieve it Using Gravic Shadowbase
®
A decade ago, it was enough for a store to remain competitive if it could determine that battery-operated power
drills were hot items and were sufficiently stocked. That ability is no longer adequate in the current aggressive
marketing environment. Today that same store needs to know that a customer who is purchasing a set of drill
bits bought a battery-operated power drill the prior month. While the customer is at the register, the store offers
him a 30% discount on an extra drill battery for purchase during his next visit. Similarly, the store offers an
online customer with a similar purchasing history the same 30% discount during his current shopping session.
This requirement for current information is needed across the board, and even aids in life-saving and rescue
operations. A decade ago, a blood bank was considered successful in meeting the needs of a community if it
could determine the most common blood types among the residents and could maintain sufficient supplies in
the local distribution center. Now, that same blood bank is expected to supply all blood types, not just the
common ones. If a local resident with a rare blood type is in a serious car accident, the blood bank either has
to have that blood type stored locally or know where it can be obtained on a moment’s notice.
In today’s competitive environment with high consumer expectation, it is decisions that are based on the most
current data available that improve customer relationships, increase revenue, maximize operational
efficiencies, and even save lives. This technology is real-time business intelligence. Real-time business-
intelligence systems provide the information necessary to strategically improve an enterprise’s processes as
well as to take tactical advantage of events as they occur.
In this white paper, business intelligence is tracked from its early days as a strategic tool to today’s real-time
capabilities for tactically responding to events as they happen. In conclusion, descriptions of the Shadowbase
suite of products from Gravic, Inc. are described, as well as several case studies where the products are
deployed. Shadowbase solutions are available today for achieving real-time business intelligence.
Business Intelligence
As information technology evolved over the years, enterprises automated more and more of their operations.
A great deal of very valuable data resided underutilized in these systems. Data found in sales, accounting,
production, human resources and many other systems could yield significant information to provide historical,
current, and predictive views of business operations. However, this data was often siloed, an “operational
island” that was not readily integratable with other business functions, as were the applications associated with
the data, making leveraging these data and applications across the business very difficult or even impossible
in real-time.
Business intelligence is the consolidation and use of an organization’s disparate data to provide meaningful
information and analyses to employees, customers, suppliers, and partners for more efficient and effective
decision-making. It transforms information into actionable strategies and tactics to: improve the efficiency of
the enterprise, reduce costs, attract and retain customers, improve sales, and provide many other significant
benefits.
Gravic, Inc. White Paper
The Evolution of Real-Time Business Intelligence and How to Achieve it Using Gravic Shadowbase
®
Page 6 of 33
For example, some typical instances of the use of business intelligence include:
The History of Business Intelligence
The Early Days of Computing
Typically, early business applications had their own databases that supported their functions, which became
siloed because no other systems had access to them. These islands of information proliferated as more and
more departments were automated. Mergers and acquisitions compounded the problem since the companies
integrated totally different systems, many of which were doing the same job.
Businesses soon recognized the analytical value of the data that they had available in their many islands of
information. In fact, as businesses automated more systems, more data became available. Collecting this data
for analysis was a challenge due to the incompatibilities between systems because there was no simple way
(and often no way) for these systems to interact. An infrastructure was needed for data exchange, collection
and analysis that could provide a unified view of an enterprise’s data, so the data warehouse evolved to fill this
need.
The Data Warehouse
The data warehouse concept (Figure 1) is a single system for the repository of all of an organization’s data.
This warehouse organizes the information so it can be effectively analyzed and meaningful reports are
prepared for management and other knowledge workers. However, meeting this goal presents several very
significant challenges:
? Data must be acquired from a variety of incompatible systems.
? The same item of information might reside in the databases of different systems in different forms.
A particular data item might not only be represented in different formats, but the values of this data
item might be different in different databases. Which value is the correct (or current) one to use?
? Data is continually changing. How often should the data warehouse be updated to reflect a
reasonably current view?
? The amount of data is massive. How is it analyzed and presented simply so that it is useful?
To meet these needs, a broad range of powerful tools were developed over the years and became productized.
They included:
? Extract, transform, and load (ETL) utilities for the moving of data from the various data sources to
the common data warehouse.
Retail:
Sales Patterns
Integrated Customer View
Campaign Management
Customer Valuation
Analytical CRM
Telecom:
Call-Behavior Analysis
Fraud Detection
Number Portability
Service-Usage Analysis
Promotion Effectiveness
Manufacturing:
Order Life Cycle
Inventory Analysis
Quality Assurance
Supplier Compliance
Distribution Analysis
Financial:
Credit Risk
Monetary Risk
Asset Management
Liability Management
Fraud Detection
Government:
National Security
Crime Analysis
Health
Welfare
Fraud Detection
All Industries:
P & L Analysis
Profitability
Performance Analysis
Value-Chain Analysis
Profiling
Gravic, Inc. White Paper
The Evolution of Real-Time Business Intelligence and How to Achieve it Using Gravic Shadowbase
®
Page 7 of 33
? Data-mining engines for complex predetermined analyses and ad hoc queries of the enterprise
data stored in the data warehouse.
? Reporting tools to provide management and knowledge workers with the results of the analyses
in easy-to-absorb formats; digital dashboards are a predominant example.
Data Warehouse
Ad-Hoc
Queries
Reports
Sales Promotions
Gift Registry
Point-of-Sale
Dashboards
ETL Batch
Transfers
Knowledge Workers
and Management
Offline Extract, Transform, and Load
Early on, the one common interface that was provided between the disparate systems in an organization was
magnetic tape. Tape formats were standardized, and any system could write tapes that could be read by other
systems, and so the first data warehouses were fed by magnetic tapes prepared by the various systems within
the organization. However, that left the problem of data disparity, since the data written by the different systems
reflected their native data organizations. The data written to tape by one system often bore little relation to
similar data written by another system.
Even more important was that the data warehouse’s database was designed to support the analytical functions
required for the business intelligence function. This database design was typically a highly structured database
with complex indices to support online analytical processing (OLAP). Databases configured for OLAP allowed
complex analytical and ad hoc queries with rapid execution time.
The data fed to the data warehouse from the enterprise systems was
converted to a format meaningful to the data warehouse.
To solve the problem of initially loading this data into a data
warehouse, keeping it updated, and resolving discrepancies,
extract, transform, and load (ETL) utilities were developed. As their
name implies, these utilities extract data from source databases, transform them into the common data
warehouse format, and load them into the data warehouse, as shown in Figure 2.
Figure 1 - The Data Warehouse
Gravic, Inc. White Paper
The Evolution of Real-Time Business Intelligence and How to Achieve it Using Gravic Shadowbase
®
Page 8 of 33
The transform function is the key to the success of this approach. Its job is to apply a series of rules to extracted
data so that it is properly formatted for loading into the data warehouse. Examples of transformation rules
include:
? the selection of data to load
? the translation of encoded items (for instance, 1 for male,
2 for female to M, F)
? encoding and standardizing free-form values (New
Jersey, N. Jersey, N. J. to NJ)
? deriving new calculated values (sale price = price -
discount)
? merging data from multiple sources
? summarizing (aggregating) certain rows and columns
? splitting a column into multiple columns (for instance, a
comma-separated list)
? resolving discrepancies between similar data items
? validating the data
? ensuring data consistency
The ETL function allows the consolidation of multiple data sources
into a well-structured database that is used for complex analyses.
The ETL process is executed periodically, such as daily, weekly,
or monthly, depending upon the business needs. This process is
called offline ETL because the target (warehouse) database is not
continuously updated; it is updated on a periodic batch basis.
Though offline ETL serves its purpose well, it has some serious
drawbacks. First, the data in the data warehouse is stale and could
be weeks-old, making it useful for strategic functions but it is not
particularly adaptable to tactical uses. Second, the source
database typically must be quiesced during the extract process,
otherwise, the target database is in an inconsistent state following
the load. As a result, the applications must be shut down, often for
hours, resulting in loss of business services to customers.
In order to evolve to support real-time business intelligence, the ETL function must be continuous and
noninvasive. This function is online ETL, which is described later. In contrast to offline ETL, which provides
stale but consistent responses to queries, online ETL provides current but varying responses to successive
queries since the data that it is using is continually being updated to reflect the current state of the enterprise.
Offline ETL technology has served businesses for decades and the intelligence that is derived from this data
informs long-term reactive strategic decision-making. However, short-term operational and proactive tactical
decision-making continues to rely on intuition, and the business service outage associated with offline ETL is
unacceptable in today’s 24 hour global economy.
Figure 2 - ETL: Extract/Transform/Load
Legacy
System
Database
Warehouse
Database
Intermediate
Database
Extract
Transform
Load
Gravic, Inc. White Paper
The Evolution of Real-Time Business Intelligence and How to Achieve it Using Gravic Shadowbase
®
Page 9 of 33
Data-Mining Engines
The ETL utilities make data collection from many diverse systems practical; however, the captured data needs
to be converted into information and knowledge in order to be useful.
? Data are simply facts, numbers, and text that can be processed by a computer. For instance, a
transaction at a retail point-of-sale is data.
? Information embodies the understanding of a relationship of some sort between data. For example,
analysis of point-of-sale transactions can yield information on consumer buying behavior.
? Knowledge represents a pattern that connects information and generally provides a high level of
predictability as to what is described or what will happen next. An example of knowledge is the
prediction of promotional efforts on sales of particular items based on consumers’ buying behavior.
Powerful data-mining engines were developed to support complex analyses and ad hoc queries on a data
warehouse’s database. Data mining looks for patterns among hundreds of seemingly unrelated fields in a large
database, patterns that identify previously unknown trends. These trends play a critical role in strategic
decision-making because they reveal areas for process improvement and business opportunity. Examples of
data-mining engines are those from SPSS
1
(IBM) and Oracle.
2
Facilities such as these are the foundation for
online analytical processing (OLAP) systems.
Reporting Tools
The knowledge created by a data-mining engine is not very useful unless it is presented clearly and concisely
to those who need it. A common technique for displaying information is the digital dashboard.
3
A digital
dashboard (Figures 3 and 4) provides a business manager with the input necessary to “drive” the business. It
is focused on providing rapid insight into key performance indicators, and consequently is highly graphical with
colored lights, alerts, drill-downs, and gauges.
A digital dashboard provides the user a graphical
high-level view of business processes that can be
drilled-down to see more detail on a particular
business process. This level of detail is often
buried deep in the enterprise’s data, making it
otherwise concealed to a business manager. For
instance, with the digital dashboard shown in
Figure 4, a knowledge worker clicking on an object
will see the detailed statistics for that object.
1
http://www-01.ibm.com/software/analytics/spss/
2
http://www.oracle.com/solutions/business_intelligence/data-mining.html
3
http://en.wikipedia.org/wiki/Dashboards_(management_information_systems)
Figure 3 - Sample Reporting Tool
Gravic, Inc. White Paper
The Evolution of Real-Time Business Intelligence and How to Achieve it Using Gravic Shadowbase
®
Page 10 of 33
Today, many versions of digital dashboards are available from a variety of software vendors. These
dashboards and other sophisticated reporting tools are the collective product of business-intelligence systems.
Driven by information discovered by a data-mining engine, they give the business manager the information
required to:
? see immediately key performance measures
? identify and correct negative trends
? measure efficiencies and inefficiencies
? generate detailed reports showing new trends
? increase revenues
? decrease costs
? make more informed decisions
? align strategies and organizational goals
Data Marts
As corporate-wide data warehouses came into use, it became clear in many cases that a full-blown data
warehouse was overkill for many applications. Data marts evolved to solve this problem and are a specialized
version of a data warehouse. Whereas a data warehouse is a single organizational repository of enterprise-
wide data across all subject areas, a data mart is a subject-oriented repository of data designed to answer
specific questions for a specific set of users. A data mart holds just a subset of the data that a data warehouse
holds.
A data mart includes all of the needs of a data warehouse – ETL, data mining, and reporting. Since a data
mart deals with only a subset of data, it is much smaller and more cost-effective than a full-scale data
warehouse. In addition, because its database is much smaller because it only needs to hold subject-oriented
data rather than all of an enterprise’s data, it is much more responsive to ad hoc queries and other analyses.
Data marts have become popular not only because they are less costly and more responsive but also because
they are under the control of a department or division within the enterprise. Managers have their own local
sources for information and knowledge rather than having to depend on a remote organization controlling the
enterprise data warehouse.
Figure 4 - Sample Digital Dashboard
Gravic, Inc. White Paper
The Evolution of Real-Time Business Intelligence and How to Achieve it Using Gravic Shadowbase
®
Page 11 of 33
Enterprise Application Integration
As data warehouse technology matured, another solution for integrating enterprise-wide data appeared, called
enterprise application integration (EAI). In many cases, the functioning of one enterprise system is significantly
enhanced if it requests data or immediately receives newly generated data from other systems. For instance,
an inventory control system could be much more responsive if it has immediate access to point-of-sale data
so that it could monitor product movement in real-time. A bank could authorize a loan to a customer while the
customer is sitting with the loan officer by analyzing in real-time the customer’s current business with the bank,
his credit worthiness, and the current equity in his assets.
This capability requires that various legacy enterprise systems with different hardware, operating systems, and
databases be enhanced so that they can talk to each other and exchange information in real-time or near real-
time. The deployment of new business services, which were impossible previously, are enabled because the
data and the applications that understood it are isolated from one another.
Intersystem Communication with EAI
EAI provides a means for linking such systems, in some cases without having to make sweeping changes to
existing applications or data structures. In effect, whenever an event occurs in an application, it is sent via a
publish/subscribe (or perhaps broadcast) mechanism to other applications in other systems that may be
interested in this event. Likewise, one system requests data from another system in real-time via a
request/response mechanism. As shown in Figure 5, there are two techniques for implementing EAI, adapters
and message-oriented middleware (MOM), and as shown in Figure 6, there are two techniques of data
replication for implementing EAI. These techniques all perform the transformation of data to a common format
to be used by all systems, the T in ETL.
Adapters
Adapters (Figure 5a) are specialized interfaces between diverse applications and allow those applications to
directly communicate, in a form that is native to each application so major application changes are typically not
required, assuming that the application or adapter vendor has already created/provided the translation and
interface for that application. The adapters perform the necessary translation to a common communications
protocol which is understood by the adapter at each end.
Adapter services must be defined by a common interchange data format to which all systems conform for their
inter-application communication. As a consequence, the use of adapters is often invasive to applications, and
can add inefficiencies to the message path length for the various translations that occur. Each application
involved in communicating with other applications must be modified to use the common data format for the
messages that it sends and receives, or an adapter must be developed to the application’s existing interface.
This problem is aggravated because knowledge is required of the proprietary formats used by the application
vendors, information which many application vendors refuse to divulge. Consequently, adapter services can
often only be implemented by the application vendor or in close cooperation with the application vendor.
4
Also, each application may need to be modified to know how to select events to send, to which systems to
send these events, how to process events it receives from remote applications, and how to respond to requests
from remote applications.
Adapters are highly specialized because each application requires its own adapter that connects to the adapter
network and that translates its application interface and data formats into the common formats of the adapter
network. The range of applications that participates in an EAI network interconnected with adapters is often
limited, and customized or “home grown” applications often do not provide the services necessary to interface.
These problems all served to inhibit the widespread use of adapters for application integration, particularly for
highly customized or “home grown” applications.
4
Of course, some applications either provide an adapter themselves or rely on one of the adapter vendors to create one or more
for them. For example, TIBCO Software, Inc. provides adapter technology for integrating many of the popular application packages.
Gravic, Inc. White Paper
The Evolution of Real-Time Business Intelligence and How to Achieve it Using Gravic Shadowbase
®
Page 12 of 33
Message-Oriented Middleware (MOM)
Message-oriented middleware (MOM) (Figure 5b) provides a mechanism for asynchronously sending
messages between applications. Messages are placed in queues and are sent to their destinations when the
destinations are available. MOM is used to queue messages describing events and to send those messages
to remote applications that take actions based on those events. MOM also provides the messaging facilities to
send requests to other applications and to receive responses to those requests.
5
However, the use of MOM in EAI suffers many of the same problems that adapters face. For one, MOM is
invasive to the application, which can be architected into new applications. However, retrofitting the MOM calls
into an existing application requires access to the application source code, intimate knowledge of the
application processing sequence, and extensive testing of the modified application. As with adapters, MOM
requires that a common data format is established between all systems so that they can understand each
other’s communications. Applications must be modified to conform to this format when they communicate with
other applications. In addition, applications must be modified to know when to send messages and how to
respond to messages from other applications, as well as how to recover/continue processing when the MOM
interface fails or becomes unavailable.
Data Replication
Data replication engines (Figure 6) exchange data between systems
at the database level. This data may take the form of events
generated by one system for consumption by other systems, or it may
take requests from one system to other systems and the responses
to those requests.
The data replication engine can replicate data
from one database to another for each
application to use (Figure 6a). This approach is
particularly useful for isolating target application
processing from interconnection issues as the
receiving database is local to the target
application environment. But auguably a more
powerful approach is shown in Figure 6b where
the database changes in the one database act as
the real-time, event-driven feed into the other
application. In order to interoperate with each
other, applications may be integrated at the
service layer or at the event layer.
With service-level integration, special interfaces
expose server-system data or application
services to external client applications. One way
to accomplish this is via specially designed
agents that reside on the server system. For
instance, a database agent may provide access
to the target database via ODBC, JDBC, OLE,
XML, or ADO.NET.
Event-level integration provides event-driven
integration services based on changes made to
the source system’s database. Event-level
integration avoids the necessity of developing
special agents or adapters for each application
5
MOM interconnects typically provide persistence of the messages being sent and returned, allowing for their asynchronous
nature. Of course, in some cases, these messages are sent synchronously, with the sending application often blocking or waiting
for the reply. In such architectures, loss of the interconnect infrastructure, even temporarily, often means the application itself is
down, or at least severely impacted. This issue can be an important design consideration especially when the interconnect spans
different systems or wide-area communications.
A
d
a
p
t
e
r
A
d
a
p
t
e
r
Point-of-Sale Inventory
Appl Appl
Data
base
Data
base
EAI with Adapters
(a)
Point-of-Sale
Appl Appl
Data
base
Data
base
EAI with MOM
(b)
Inventory
Figure 5 - EAI Intersystem Communication
Gravic, Inc. White Paper
The Evolution of Real-Time Business Intelligence and How to Achieve it Using Gravic Shadowbase
®
Page 13 of 33
that is to be integrated. Rather, it monitors source application events in real-time and sends them immediately
to the target application so that action can be taken on the event by the target.
Notice that this description has used the term “system” rather than “application,” as was used in the descriptions
for adapters and MOM. There is no integration with the data replication engine at the application level. Rather,
replication works at the database level and occurs without any modification to the applications, which are
typically unaware that replication is taking place. The only application modifications necessary are those
required to implement new functions that make use of information from other systems. i.e., to take advantage
of the availability of more information to more applications, enabling the rapid implementation of new business
services.
A replication engine monitors changes to a
system’s database and is driven by a change log
or by database triggers. Based on rules
incorporated into the replication engine, certain
database changes found in the change log are
sent to other systems in the application network.
Alternatively, database triggers can pass critical
changes to the replication engine for
dissemination to other systems. These changes
are either placed in tables in the target systems
(Figure 6) or are otherwise delivered to the
applications via an interprocess message,
MOM, or queue and may be then used by
applications to implement new functionality for
the enterprise.
In addition to the advantage of noninvasiveness
described above, data replication has other
benefits over directly using adapters and MOM.
For one, with adapters or MOM, the
unavailability of the network or another system
brings down the application because it no longer
has access to the data that it needs. With
replication, applications continue to function in
the presence of network failures or external
system outages by using the local copy of the
application database.
Data replication also brings locality to the
application since the application has access to a
local copy of the database. Since it does not reach across the network for data, performance is greatly
enhanced. A common interchange data format is not required when using data replication engines, since the
transferred data must be put into the target tables or target application’s request format according to specified
formatting rules. The transformation of source data to target data is performed by the data replication engine
according to transformation rules specified by the user and incorporated directly into the engine. Applications
access the new data or receive the new requests just as they would access any data or request.
Another advantage of data replication engines is that security is significantly simplified. With adapters and
MOM, every application is an interface and must be secured via encryption. Data replication engines present
only a single interface that must be secured. Not only is the management of security simplified, but the number
of points that may be attacked are also reduced.
Sophisticated data replication technologies (such as the Gravic Shadowbase product portfolio, discussed
further below), also provide mechanisms to not only replicate data between systems, but also to feed database
changes directly to applications by sending events to client applications or servers via queues or client APIs,
publishing data to applications that have subscribed to the data, or responding to poll queries
Point-of-Sale
Appl Appl
Data
base
Data
base
EAI with Data Replication (a)
Point-of-Sale Inventory
Appl Appl
Data
base
Data
base
EAI with Data Replication (b)
Inventory
Replicator
Replicator
Figure 6 - EAI Intersystem Communication
Gravic, Inc. White Paper
The Evolution of Real-Time Business Intelligence and How to Achieve it Using Gravic Shadowbase
®
Page 14 of 33
from client applications. Since data replication avoids the application-specific problems associated with
adapters and MOM, this mechanism has become the technique of choice for EAI.
EAI Networks
EAI networks may either be mesh networks or hub networks. In a mesh network (Figure 7a), every system is
potentially connected to every other system. In a hub network (Figure 7b), all systems communicate via a
central hub that passes data to the target systems.
Sales Promotions Sales Promotions
Gift Registry
Gift Registry
Point-of-Sale
EAI Mesh
Network
(a)
Publish/Subscribe/
Request/Reply
EAI Hub
Network
(b)
Point-of-Sale
Hub
Figure 7 - EAI Networks
A problem with a mesh network is the number of possible connections. If there are n systems in the EAI
network, there can potentially be n(n-1)/2 connections if all systems have to communicate with all other
systems. If a new system is added to the network, n new connections may need to be established, one to each
of the existing systems. This number of connections creates a network complexity that rapidly becomes
unmanageable as the network grows.
A hub network eliminates this problem, as each system is connected only to the hub, which receives messages
from each system and routes each message to the appropriate target systems. A problem with a hub is that it
is a single point of failure, and a hub failure disrupts all functions that require data from other systems. Thus,
all benefits of EAI are lost during a hub failure. Since these messages are functions that are tactical in nature,
governing the real-time response of the enterprise to events as they happen, enterprise operations may be
severely compromised following a hub failure. Consequently, the hub must be made redundant so that it is
highly available.
Another difference between mesh and hub networks is that in a mesh network, every system must know the
data format of every other system. Each system must be able to transform its data format into those of the
other systems. But In a hub network the hub is responsible for data transformation. Each system need only
know the data format expected by the hub.
These issues notwithstanding, a mesh network does have the advantage of avoiding a potential bottleneck at
the hub for information exchange, particularly if the systems are located close to one another but the hub is
remote. If message latency is of paramount importance, or if a hub design can be overwhelmed with request
arrival rate spikes, then a mesh design may be appropriate for at least for some of the connections.
Gravic, Inc. White Paper
The Evolution of Real-Time Business Intelligence and How to Achieve it Using Gravic Shadowbase
®
Page 15 of 33
EAI and Business Intelligence
Using these techniques, EAI allows applications to integrate on a real-time basis as events occur and as
databases are updated without having to wait hours, days or weeks for data from a data warehouse.
Consequently, EAI supports tactical decision-making very well, but it does not provide the historical data
needed for strategic decision-making.
Operational Business Intelligence
Operational business intelligence (OBI) systems provide an intermediate step toward satisfying the strategic
needs that data warehouses address as well as the tactical decision-making that EAI addresses. An OBI
system provides an event database that is frequently updated. As an historical database, the event log
summarizes and satisfies strategic requirements. With frequent updates, strategic decision-making extends to
daily or intra-day information that is used to immediately take operational action to address an immediate
problem.
Colin White, a leading author and consultant in the field of business intelligence, noted that competitive
pressures are forcing companies to react faster to changing business conditions and customer requirements.
Business intelligence (BI) that helps drive and optimize business operations on a daily basis and sometimes
used for intra-day decision-making, is called operational business intelligence. Since the objective of
operational BI is to make more timely business decisions, it has a close relationship to real-time or right-time
BI processing.
Indeed, OBI systems abound today. Conceptually, OBI systems are thought of as a data mart that is updated
frequently (daily, every few hours, or even every few minutes or seconds) with minibatches.
6
OBI systems are
similar to data marts because they generally focus on a specific task rather than on enterprise-wide functions.
For instance, as shown in Figure 8, an OBI system might be periodically fed ATM and point-of-sale (POS)
transactions. Its data-mining engine will then search for potentially fraudulent activity and prepare reports of
such activity. After a review of these reports, a hold might be put on some credit or debit cards until the activity
is resolved.
OBI systems bring together two needs for business intelligence, an historical database for strategic analysis
and the capability to make rapid suggestions for operational actions. But what is still missing is the capability
to make real-time suggestions for actions that are taken immediately upon the occurrence of some specified
event; this capability is real-time business intelligence (RTBI).
Real-time business intelligence is also known as event-driven business intelligence. In order to react in real-
time, a business intelligence system must react to events as they occur, and not minutes or hours later. After
all, if one can use RTBI to stop suspected or fraudulent activity before it completes, enhance a shoppers
online experience, and/or upsell additional products, RTBI has created real, measurable business value for
the organization’s bottom line.
6
A “minibatch” (or “microbatch”) is a collection of data updates (transactions) captured during some prescribed time window, and
trickle-fed to the OBI system to keep it current.
Transaction
Database
Data-Mining
Engine
Operational Business Intelligence System
Hourly/Daily
Minibatches of
Transactions
Suspected
Fraud Report
Figure 8 - A Fraud Detection OBI System
Gravic, Inc. White Paper
The Evolution of Real-Time Business Intelligence and How to Achieve it Using Gravic Shadowbase
®
Page 16 of 33
The following are architectures that allow a business to react proactively in real-time to events as they occur
rather than reactively at some time after they have happened.
Real-Time Business Intelligence
Yesterday’s Data is No Longer Sufficient
Data warehousing solves a strategic need of the enterprise because it manipulates massive amounts of data
via data mining to derive new information and knowledge of an enterprise’s operations. However, data
warehousing has little tactical value since the data in it is generally quite stale and can be days or weeks old.
Data warehousing’s primary value is in supporting strategic goals such as reducing costs, increasing sales,
and improving profits. Even though EAI solves a tactical need of the enterprise since it allows systems to react
immediately to events generated by other systems, it has little strategic value since it provides no repository
of data suitable for data mining.
A solution is needed that satisfies both the strategic and the tactical needs of an enterprise. A store, for
instance, needs to know that men who purchase diapers on Saturday also tend to buy beer at the same time.
A strategic way to capitalize on this information would be to put the beer near the diapers, and have beer sales
on Saturday. A credit card company needs to know that a credit card being used to purchase an item in New
York City was used thirty minutes earlier in Amsterdam. A tactical way to capitalize on this information would
be to deny the transaction, and place a hold on the card.
Another example of the use of real-time business intelligence is in customer support. For instance, a customer
often needs to know if he has enough credit or cash on his credit card or in his debit card account before
attempting to make a purchase. Some card companies allow a customer to get preauthorization for specified
amounts via cell phone to ensure that the purchase is covered, meaning that the card company must have up-
to-date balances for its customers.
Today’s Business Intelligence Needs
The gap between analytical and operational processing is closing fast. Just as Moore’s Law
7
continues to
characterize the rapid pace of technology development, the complex data-mining queries that used to take
hours to run now execute in seconds. If only these data-mining engines had the latest values of the data, the
tactical and strategic needs of business intelligence could be merged into a single solution. There are two
primary impediments to effective and efficient real-time business intelligence: data latency and data
unavailability.
Data latency refers to the staleness of data. The value of data degrades rapidly with its age. When people are
relying on real-time business intelligence to tactically help them with on-the-spot decisions, the freshest data
and the fastest response times are needed.
Data unavailability is a death knell for businesses. If a company’s operations have progressed to the point that
they are dependent on real-time business intelligence, the unavailability of this intelligence due to a failed
system could bring operations to a halt, so extreme availability of the real-time business intelligence services
is paramount.
A business cannot respond to events as they happen if it cannot find out about these events for hours, days,
or weeks (data latency). It also cannot immediately respond to events if the system that supplies the analyses
of these events is down (data availability). If the problems of data latency and data availability are solved,
businesses can react proactively to new information and knowledge rather than reactively. These problems
are solved by sophisticated data replication engines such as Gravic Shadowbase.
7
http://en.wikipedia.org/wiki/moore's_law
Gravic, Inc. White Paper
The Evolution of Real-Time Business Intelligence and How to Achieve it Using Gravic Shadowbase
®
Page 17 of 33
Real-Time Business Intelligence Systems
Even though OBI systems represent a significant improvement in reducing data latency and enabling actions
to be taken within hours of the events that triggered them, they do not meet the criterion of immediacy that will
allow a business to react in real-time to an event. For instance, an OBI system does not generate an offer to a
customer while he is checking out at a cash register. Nor does it deny a potentially fraudulent transaction
before it is executed.
An OBI system is needed that responds to events in seconds or less; but this response is not done by updating
the OBI database with hourly minibatches. Rather, the database must be updated with transaction activity in
real-time as it occurs; this type of update is called trickle-feeding the database. As transactions are received,
they are stored and become a growing historical record of activity.
There must also be a very fast rules engine that analyzes incoming transactions against the historical database
and makes decisions quickly enough so that immediate action of value to the enterprise are taken; this action
is real-time business intelligence (RTBI). There is a distinction between a data-mining engine and a rules
engine. Both require an historical database; but a data-mining engine looks for relationships in the historical
data to reactively support decision-making after the fact. A rules engine compares a real-time event to the
historical data to proactively suggest an action to be taken.
Figure 9 shows the extension of the fraud detection OBI system of Figure 8 to an RTBI system that reacts fast
enough to cause a suspicious transaction denial before it is consummated. In this example, ATM and POS
transactions are fed to the RTBI system as they are generated. The RTBI system posts each transaction to its
database for use by a rules engine that is triggered by the new transaction. In real-time, the rules engine
checks this transaction against recent activity on the credit or debit card and makes an instant determination
of suspicious activity. It then generates a message indicating whether the transaction should be accepted or
denied.
This particular fraud detection example is actually used in real life, as shown in Figure 10. ATM and POS
machines are generally serviced by some particular bank, but the credit or debit card used was probably issued
by some other bank. The card transaction must be sent to the issuing bank for authorization, and verification
that the card balance is sufficient and if so authorizes the transaction.
In this case study, a bank service company operates a transaction switch that receives card transactions from
the servicing banks operating the ATM or POS machines and forwards these transactions to the appropriate
issuing banks. Upon receipt of an accept/deny message from the issuing bank, the transaction switch returns
this message to the servicing bank, which then takes appropriate action to accept or deny the transaction.
Transaction
Database
Rules Engine
Real-Time Business Intelligence System
Real-Time ATM/
POS Transaction
Authorize/
Deny a
Transaction
Figure 9 - A Fraud Detection RTBI System
Gravic, Inc. White Paper
The Evolution of Real-Time Business Intelligence and How to Achieve it Using Gravic Shadowbase
®
Page 18 of 33
Issuing Bank
Transaction
Switch
ATM/POS
Servicing Bank
Fraud Detection
RTBI System
Additionally, the bank service company provides a fraud detection service. At the same time that it forwards
the transaction to the issuing bank for authorization, it also sends the transaction to its RTBI fraud detection
system. If this system determines that the transaction is suspicious, the bank service company takes several
actions as requested by the issuing bank. It certainly denies the transaction and informs the issuing bank, but
it may also alert the issuing bank to the circumstances of the suspicious activity so that it can decide whether
or not to put a hold on the card. This system shows RTBI in action as the RTBI fraud detection system uses
complex rules against an historical database to determine which actions to take that directly affect a transaction
in progress.
RTBI Dashboards
Real-time business intelligence dashboards are used to bridge the gap between operational business
intelligence and real-time business intelligence. For instance, Figure 11 shows an IT server network monitoring
dashboard, which displays not only historical information but also shows the current status of the server
network. The dashboard is interesting because it performs all three business intelligence functions, strategic,
operational, and tactical.
From a strategic viewpoint, it shows bandwidth usage and connection quality over the last several weeks, and
by clicking on the History tab, further historical usage and quality data is displayed. This dashboard forms the
basis for future planning of network upgrades. From an operational viewpoint, the dashboard shows the current
status of the network, the current memory usage, and the current connections and their traffic. If a network
problem occurs, operational staff could immediately take remedial action. From a tactical viewpoint, as
problems are detected, the RTBI system driving the dashboard can issue audible, email, or cell phone alerts
to the operations staff. The RTBI system even takes automatic remedial action such as rerouting network
connections, shedding low-priority traffic, or invoking redundant connections. The transactions are fed to the
new RTBI system from the enterprise’s other systems with the online ETL.
Figure 10 - A Real-Time Business Intelligence Example
Gravic, Inc. White Paper
The Evolution of Real-Time Business Intelligence and How to Achieve it Using Gravic Shadowbase
®
Page 19 of 33
Online ETL
ETL is the facility that allows data to be extracted from a source database, transformed into a common format,
and loaded into a target database (the data warehouse’s database). Since contemporary ETL facilities are
batch-oriented and run periodically, they are characterized as being offline ETL facilities. EAI exchanges
current information between systems in an application network but provides no historical record of enterprise
activity for strategic analysis purposes.
Real-time business intelligence needs an online ETL facility that not only preserves historical strategic data
but can also provide current tactical data. The online ETL’s job is to create and maintain a synchronized copy
of a source database on a target database (the RTBI system) while the source database and the target
database are actively updated and used by multiple applications. In effect, as transactions occur in the
enterprise, they are trickle-fed to the RTBI system in such a way that this activity is transparent to other ongoing
operations. As with EAI, three methods can be used to create an online ETL facility – connecting via adapters,
using message-oriented middleware, and synchronizing via low-latency replication engines.
Adapters
Early adaptations of RTBI used an extension of existing EAI technology. Adapters were used to interconnect
enterprise systems with the RTBI system. As transactions were executed by an external system, the results of
those transactions were communicated to the RTBI system via adapter connections. The adapters also
serviced requests from external systems and returned the RTBI system replies to those systems.
However, adapter technology suffered from the same problems that it faced in EAI applications. It was invasive
and often required application modification in order for the applications to interface with the adapters. In
addition, adapters were specialized to the applications. Each adapter knew the proprietary formats of the
application data structures and how to interface to its application and was thus custom designed for that
application. Every time the application changed, the adapter was modified, so consequently, not all applications
could participate in the online ETL function.
Message-Oriented Middleware
MOM also exhibited many of the same problems that plagued adapters. MOM was invasive and required
changes to the application to send and receive appropriate messages in a common interconnect data format,
or to use adapters. In order to make application changes, access to the application’s source code was required,
but this source code was often lost or was the proprietary property of a third-party vendor, and so was not
available. Additionally, every time the application changed, the MOM code potentially had to be modified. As
with the EAI implementations, adapters and MOM RTBI implementations also suffered from the problems
related to network interconnect issues. Due to the immediate nature of RTBI, if the interconnect went down,
the RTBI response was either delayed, or worse, failed altogether.
Figure 11 - Sample RTBI Dashboard
Gravic, Inc. White Paper
The Evolution of Real-Time Business Intelligence and How to Achieve it Using Gravic Shadowbase
®
Page 20 of 33
Data Replication
Data replication solves the adapter and MOM problems of
application invasiveness and specialization, as well as data
availability, in an RTBI environment. Because a data replication
engine (Figure 12) is noninvasive and is application-unaware, it
deals only with the database, and so is isolated from the application
by the database. Today’s replication engines support most
relational databases and many non-relational databases as well. An additional benefit is that the same data
replication engine,such as Gravic Shadowbase, can also serve other purposes at the same time as fulfilling
the RTBI mission, for example, providing business continuity and disaster recovery.
Data replication is synchronous
(data is replicated to the target
system concurrent with the
application data changes) or
asynchronous (data is
replicated to the target system
some very short time after the
application has made its
changes). In RTBI applications,
asynchronous replication is
generally used, allowing the
replication activity to be totally
transparent to the application.
The application proceeds with
no knowledge of or impact from
the replication activity and the
application’s database activity is extracted by the replication engine via a transaction log, triggers, or intercepts.
Selected updates are sent to the RTBI target system by the replication engine, where they are applied. The
replication latency interval, which is the time that it takes to propagate a source database change to the target
database, is measured generally in sub-seconds.
Replication engines support rules for data transformation. Since some rules are built in, and others are
specified by user-supplied routines, data transformations of any kind are possible without modifying the
applications, the databases, or the core replication engine.
Since replication engines are required to preserve transactional consistency, source updates are not randomly
applied to the target database. Transactions must be applied in the same order to the target database that
they were made at the source database.
An additional problem, called a data collision, occurs when multiple sources simultaneously update their copy
of the same data item. For instance, what happens if two enterprise systems update the same customer
address with different data at the same time? Which one is correct?
Data collisions may happen with any asynchronous mechanism used to feed the RTBI system, whether it is
replication, adapters, or some other form of messaging. Data collisions do not occur if synchronous replication
is used. Most replication engines are particularly adept at handling collisions, detecting and resolving a collision
via specified rules. Some of these rules are built in, and more application-dependent rules are added via user-supplied
routines.
Another problem can occur if a target system fails, and during its downtime, other external applications try to
send it data. If an application does not get a response to its sent data, the application may fail or its data may
be lost. However, replication engines queue this data and will send the data updates to the system when it is
returned to service. As discussed below, in the unlikely event of an RTBI system failure, the replication engines
in each enterprise system queue their data changes and send them to the RTBI system when it is returned to
service, and no valuable business data is lost.
Source
Data
base
RTBI
Data
base
TX Log
Application
Transactions
Replication
Engine
Figure 12 - Data Replication
Gravic, Inc. White Paper
The Evolution of Real-Time Business Intelligence and How to Achieve it Using Gravic Shadowbase
®
Page 21 of 33
A similar problem can occur when a communication connection is lost. With data replication, a system that
loses its connection with an RTBI system continues to operate in so-called split-brain mode. It is unaffected
except that it does not send its data updates to the RTBI system, and it does not receive updates or
recommended actions from the RTBI system. When the connection is restored, all of the updates that
accumulated in either direction are sent to the opposite system via the queues maintained by the replication
engines. In split-brain mode, each system applies updates to its local copy of the data invisibly to the other
system while the connection is down; so there are bound to be data collisions. These collisions are resolved
on-the-fly by the replication engines after recovery of the network and during the resynchronization of the
databases.
Online Copying
Another requirement for online ETL is an online copy utility, which is needed to bring an RTBI system into
operation. An up-to-date snapshot of the data in the various enterprise systems that will feed the RTBI system
must first be loaded into the RTBI system before it becomes effective. This load must occur without affecting
the source systems since they are busy running the enterprise and must include all the various changes that
occur during the copy, which could take hours or even days to complete.
Additionally, the copy must include all of the transformations that were otherwise made by the online ETL
facility in order that the initial RTBI database properly reflects the state of the enterprise. The Shadowbase
SOLV product from Gravic meets all these requirements, and is discussed further below.
Extreme Availability
Once an enterprise activates real-time business information, it would suffer greatly if it lost this capability.
Instant reactions that made it competitive and efficient would be suddenly lost. Extreme availability of the real-
time business information system is of paramount importance.
The first step is to choose an architecture that is especially resilient to failure. NonStop systems from HP are
an ideal solution. These totally redundant systems provide proven availabilities in excess of four 9s (less than
one hour of downtime per year).
8
Clusters of highly reliable industry-standard servers using RAID or mirroring
storage are another choice and are configured to provide availabilities in the same range as HP NonStop
systems, but are much more complex to manage and generally have a higher total cost of ownership (TCO)
9
.
Though these solutions give reasonable protection against single component failures, they do nothing for
disasters that take out an entire data center. The RTBI system must be backed up by a geographically remote
site that takes over in the event of a primary site failure. Otherwise, it might take days or weeks to replace the
system, during which time normal business operations are severely impacted.
Backup systems using magnetic tape to rebuild the database take days to recover and are unsuitable for RTBI
system backup. Virtual tape eliminates some of the problems associated with magnetic tape, but virtual tape
systems still take a prohibitively long time to recover. Data replication to a backup site provides a reasonably
complete copy of the database, but following a primary site failure, the database must still be brought to a state
of consistency, the applications started, the database opened, and the system tested before it is returned to
operation. This strategy takes some time (minutes to hours) and is hindered by the same problem that the
other backup strategies face, questioning whether or not the backup system will properly come up when it is
brought into operation.
8
For a further discussion of 9s as a measure of availability, see The 9s Game, Chapter 1 of Breaking the Availability Barrier:
Survivable Systems for Enterprise Computing, AuthorHouse; 2004.
9
For more information on TCO, see the Gravic article, Why Your Business Continuity Plan May be Inadequate.
Gravic, Inc. White Paper
The Evolution of Real-Time Business Intelligence and How to Achieve it Using Gravic Shadowbase
®
Page 22 of 33
The best “backup” for an RTBI system is an active/active system.
10
An active/active system comprises two or
more geographically-dispersed nodes that are already up and running, with each node actively processing and
sharing the application load with the other nodes. If a node fails, transactions (or users) must be switched from
the failed node to the surviving nodes, a switch that can be done in seconds.
The primary advantages of having an RTBI active backup are twofold. First, failover is accomplished in
seconds. Users of the real-time business information facilities may not even know that a failure has occurred.
Second, the failover process itself does not fail. Since the backup system is already up and running, it is known
that it is fully operational, and its operation is being verified with every transaction it processes.
For some applications or other operational reasons an active/active RTBI configuration may not be possible.
An alternative which may be used in such cases is known as sizzling-hot-standby. The only difference between
this alternative and an active/active configuration is that the standby system is not actually processing
transactions, in all other respects it is identical, and shares all the advantages of an active/active system.
As previously stated, there are two impediments to real-time business intelligence, data latency and data
unavailability. Online ETL (and especially data replication) solves the problem of data latency. Active/active or
sizzling-hot-standby RTBI systems solve the problem of data unavailability.
The Operational Data Store – The Next Evolutionary Step?
What is an Operational Data Store?
In the early 2000s, the Gartner Group coined the term zero latency enterprise (ZLE). In its words, ZLE was
“the instantaneous awareness and appropriate response to events across an entire enterprise.” This response
was later renamed the real-time enterprise (RTE).
HP was a leader in ZLE, with its ZLE architecture centered around an operational data store (ODS) that was
similar to the data store used by a data warehouse. Rather than periodically loading the ODS with massive
amounts of data via an ETL facility, the ODS was trickle-fed transactions as they occurred so that it always
contained the latest state of the enterprise as well as historical information (Figure 13). Using the ODS,
classical data-mining engines could generate strategic information and knowledge, and real-time rules engines
could make tactical decisions regarding immediate actions to take.
One particular ODS characteristic requires it to handle mixed workloads. On the one hand, it must be able to
respond to complex queries from knowledge users, data-mining facilities, and rules engines using online
analytical processing (OLAP). The database structures suitable for OLAP are characterized by fat keys that
allow rapid searching of the database to respond to complex queries. On the other hand, the ODS must be
capable of online transaction processing (OLTP) at an extremely high transaction rate, as it is being fed
transactions in real-time from many enterprise systems. The database structures suitable for OLTP are
characterized by skinny keys that require a minimum of updating as data is added to the database.
Another particular ODS characteristic is that it is bi-directional. Unlike a data warehouse, which only accepts
information from enterprise systems, an ODS both accepts information from and delivers information to the
other enterprise systems. An example of this characteristic is the act of keeping databases in synchronization.
A particular data item, like a customer’s address, may be stored in several databases around the enterprise. If
one system changes this data item, the ODS acts as a central data repository that informs the other systems
of the new data value so they update their databases.
For more information on active/active systems, see the Gravic white paper, Achieving Century Uptimes with Shadowbase
Active/Active Technology.
Gravic, Inc. White Paper
The Evolution of Real-Time Business Intelligence and How to Achieve it Using Gravic Shadowbase
®
Page 23 of 33
Operational Data Store (ODS)
Replication
Dashboards
Strategic Applications
Tactical
Rules-Based
Applications
Ad-Hoc
Queries
Reports
Gift Registry
Point-of-Sale
Rules Engine
Sales Promotions
Another example of outgoing information are the results of the rules engine. If the rules engine decides to
recommend a particular immediate action, that action is communicated to the appropriate enterprise system
for execution. For instance, if the rules engine for a credit card processor detects suspicious activity, it
immediately alerts the authorization system to take appropriate action.
In concept, the ODS, which contains all of a corporation’s data, could become the database of record, the
single version of truth. This action generally does not happen because of regulatory requirements and other
considerations and the database of record remains on the existing systems, where it was resident for decades.
The Evolution of RTBI to ODS
As previously described, the ODS is simply the RTBI system but extended to the enterprise. Though RTBI
systems are becoming common today, full-blown ODS systems have yet to make a significant appearance
due to the complexity and cost of designing and building such far-reaching systems.
It is conceivable that RTBI systems may evolve eventually to ODS systems, as shown in Figure 14. Early
dedicated business intelligence systems used data warehouse or EAI technologies. As these technologies
proved their worth, data replication was added to move the technologies to real-time business intelligence
systems, thus expanding their reach. Though RTBI systems exist today in many applications, each RTBI
system generally supports a single purpose such as fraud detection, instant customer promotions, or just-in-
time inventory.
Considerable effort was invested by some companies to consolidate a multitude of RTBI systems into a single
ODS supporting enterprise-wide tactical and strategic decision-making, shown as the final step in Figure 14.
The cost and disruption imposed by conversion to an ODS has so far resulted in little progress in expanding
RTBI systems to support both tactical and strategic decision-making for any particular corporate function, much
less the enterprise. The advantages of such integration are clear:
? The single ODS supports both tactical and strategic decision-making.
? The ODS is made highly available through redundancy, such as using an active/active system to
achieve not only high availability of the system, but also to achieve disaster tolerance. Corporate
functions are less affected by the failure of one of the other systems. For example, a customer’s credit
status is checked against the ODS without having to interrogate a credit-authorization system that
might be down.
Figure 13 - The Operational Data Store
Gravic, Inc. White Paper
The Evolution of Real-Time Business Intelligence and How to Achieve it Using Gravic Shadowbase
®
Page 24 of 33
? The scope of decision-making is extended to many more areas across the enterprise. For instance, a
drop in sales is correlated with increased accounts receivables on store-branded credit cards. Easier
credit terms might help to restore sales to their previous level.
? The various corporate IT systems are isolated. No longer do they have to interact with each other
through EAI. They each communicate only with the ODS system. Newly added applications do not
have to be configured to interface with multiple other applications and only need to interface with the
ODS. Also, other systems do not have to be modified to interface with the new system.
The obstacles to achieving this goal have been daunting so far. For instance:
? The ODS is an expensive system in terms of hardware acquisition, software licensing, and
development.
? More powerful data-mining engines and rules engines may need to be incorporated.
? The design of the ODS database is much different and needs to support both tactical and strategic
queries, yet be very efficient in handling a large volume of updates. Fast update processing requires
? skinny keys in which a minimum of alternate indices must be updated, while efficient query processing
requires fat keys providing many access paths to the data.
? The size and depth of the ODS can be quite extensive, as it typically has to store large volumes of
historical and archival versions of the data, instead of just the current value of the data (also referred
to as managing long data issues).
? Current database products tend to handle structured data well, but corporations also want to leverage
their unstructured data (e.g., video, email, voice, text) for business gain. So-called big data collection,
indexing, and accessing issues tend to thwart co-locating all of this information into a
Real-Time
Business
Intelligence
Real-Time
Business
Intelligence
BI
data
base
BI
data
base
Real-Time
Enterprise
Data
Warehouse
DW
Data
base
Real-Time
Data Marts
DM
Data
base
BI
data
base
Business
Intelligence
Business
Intelligence
BI
data
base
Batch Updates
Data Marts
Enterprise
Data
Warehouse
DW
data
base
DM
data
base
Batch Updates
Real-Time Updates Real-Time Updates
DATA CONSOLIDATION
E
v
o
l
u
t
i
o
n
o
f
B
u
s
i
n
e
s
s
I
n
t
e
l
l
i
g
e
n
c
e
TACTICAL STRATEGIC
operational data
store
tactical/strategic
Real-Time
Business
Intelligence
Real-Time
Enterprise
Data Warehouse
Real-Time
Data Marts
Real-Time Updates
C
o
n
s
o
l
i
d
a
t
i
o
n
o
f
B
u
s
i
n
e
s
s
I
n
t
e
l
l
i
g
e
n
c
e
Figure 14 - The Evolution of the Operational Data Store
Gravic, Inc. White Paper
The Evolution of Real-Time Business Intelligence and How to Achieve it Using Gravic Shadowbase
®
Page 25 of 33
single repository, managed by a single DBMS. The volume of data generation overwhelms typical
storage capacities. Clearly, more powerful data collection, transmission, storage and retrieval systems
are needed.
? Applications may have to be significantly rearchitected, which is not only expensive and time
consuming, but risky.
? Third-party products that do not readily lend themselves to adapting to an ODS architecture may be
involved.
? The conversion of current decision-making processes might not only be difficult but may, in fact, be
resisted by the user community.
The bottom line is that today, companies are achieving RTBI by directly integrating their systems using real-
time data replication, or they are trickle-feeding data marts in real-time and using these to gather information.
These warehouses or application networks may or may not turn into an ODS as consolidation occurs. If no
warehouse currently exists to act as the stepping stone to an ODS, companies may find it more economical to
simply interconnect their systems in a mesh network using existing EAI technologies, instead of following a
more planned, fruitful, but expensive path to an ODS.
Real-Time Business Intelligence Solutions from Gravic
This paper has laid out the evolution of RTBI, and the various technologies that over the years have been used
to achieve it. It has demonstrated that of these technologies, data replication is by far the most flexible, least
disruptive, and easiest to implement. The Shadowbase suite of products, from Gravic, Inc.
(www.gravic.com/shadowbase), provides the replication and online copying facilities needed for effective real-
time business intelliigence systems. These products also provide the infrastructure to implement extreme
availability architectures and include Shadowbase, a real-time data replication engine, and SOLV, a powerful
online copy utility.
Shadowbase Software – Real-Time Replication
The Shadowbase data replication engine provides high-speed data replication among a variety of databases
and platforms. With a history in the decades and hundreds of large, mission-critical, enterprise-class
installations worldwide, the Shadowbase engine is a proven performer and is an ideal solution for
interconnecting enterprise systems with an RTBI system. Shadowbase software:
? provides uni- and bi-directional asynchronous data replication, supporting active/passive, sizzling-
hot-standby, and active/active system configurations. Shadowbase synchronous data replication
is under development. (Contact Gravic for more information.)
? is totally transparent to the applications. It requires no application modifications because it gets
database changes from a transaction log or from database triggers or intercept libraries.
? runs on a wide variety of platforms against several databases; source platforms include HP
NonStop, Linux, Unix, and Windows. Target platforms include all source platforms plus
OpenVMS and AS400. Shadowbase replicates from NonStop SQL, Enscribe, Oracle, Sybase, and
SQL Server databases to these same databases as well as to DB2 and MySQL database, and
can also replicate to any ODBC-compliant target database. (See www.gravic.com/shadowbase for
the current list of supported databases.)
? has no disk-queuing points, so replication is very rapid. Replication latency is measured in the tens
of milliseconds on many systems and performance is enhanced by its multithreading capability.
? runs as checkpointed process pairs and persistent processes on HP NonStop systems so that it
survives hardware and software failures. On other systems, its processes run as persistent
processes under a monitor.
Gravic, Inc. White Paper
The Evolution of Real-Time Business Intelligence and How to Achieve it Using Gravic Shadowbase
®
Page 26 of 33
? guarantees the integrity and consistency of the target database even when running with multiple
threads. Alternatively, it is configured to break source transactions into subtractions to enhance
replay parallelism and performance.
? has extensive built-in data transformation rules that are augmented by user-supplied specialized
rules.
? provides complete data collision detection and resolution facilities for active/active environments.
Users extend its collision resolution rules with additional business rules tailored to their
application’s business logic.
? is heterogeneous; any supported platform and any supported database may serve as a source
system or as a target system in any mix.
? is easy to manage with its AUDMON process monitor, its AUDCOM command interface, and its
Shadowbase Enterprise Manager (SEM), a Windows GUI that provides integrated command and
monitoring support for its components running in a heterogeneous environment.
Extreme Availability with Shadowbase Active/Active Support
Many Shadowbase installations around the world are active/active, geographically distributed systems. These
systems achieve availabilities in excess of six 9s (less than thirty seconds per year of downtime). Shadowbase
replication provides two functions in an RTBI environment: it synchronizes the operational systems with the
RTBI system and synchronizes multiple RTBI systems in a redundant active/active or sizzling-hot-standby
configuration.
Running an RTBI system as an active/active system simply requires that the Shadowbase engine replicates
database changes between the two geographically separated RTBI systems. If one system fails, the other
system is immediately ready to take over the real-time business intelligence services. With an active/active
RTBI system, it is fair to say that the uptime of real-time business intelligence services is measured in centuries.
Shadowbase SOLV – Online Copying
The critical online copying function needed to bring an RTBI system
into service is provided by the unique copying utility, Shadowbase
Online Loading (SOLV), which:
? moves data from a source database to the target
database without interrupting source database activity.
? maintains target data that was already copied in a current state by applying changes to it as other
portions of the source database are copied. There is no large queue of source database changes
that needs to be applied following the copy.
? maintains currency of those parts of the database that were already copied, which may then be
used by applications at the target system while the copy is in progress.
Another powerful feature of SOLV is inherent in its architecture. Since SOLV is not a utility separate from the
Shadowbase replication engine, it uses the Shadowbase replicator to move data from the source database to
the target database. As a consequence, SOLV uses the same data transformation rules during the copy
function that the Shadowbase engine uses during later data replication. This function avoids the problem of
trying to conform the copy transformation rules with the replicator transformation rules so that both perform
exactly the same. Rules are implemented only once because the same code is then used by both the load
engine and the replication engine.
Gravic, Inc. White Paper
The Evolution of Real-Time Business Intelligence and How to Achieve it Using Gravic Shadowbase
®
Page 27 of 33
Shadowbase Streams
Shadowbase Streams, another member of the Shadowbase
product line, streams data generated by one application to other
applications and facilities as well as target database environments.
Shadowbase Streams for Data Integration and Application
Integration provides the facilities for integrating existing applications
at the data or event-driven level in order to create new and powerful
functionality for the enterprise. Shadowbase Streams:
? quickly and easily integrates changes made in any database into other data environments to keep
that target information synchronized. The changes can be made in real-time or batched for periodic
snap-shot or micro-batch updating.
? interoperates applications that were once isolated in an event-driven fashion in real-time. Critical
data generated by one application is distributed and acted upon immediately by other applications.
? supports many models for data distribution, including maintaining a remote database of critical
data, sending critical data to client applications or servers directly via queues or client APIs,
publishing data to applications that have subscribed to the data, and responding to poll queries
from client applications.
? is extensible, allowing the user to embed custom processing logic into the data processing path.
It readily filters, transforms, and adapts data from one application or database environment into
the format or protocol required by another application or database environment, all without
requiring any changes to the existing application that is generating the data.
? modernizes legacy applications by integrating diverse applications across the enterprise so that
new and valuable services are generated to enhance competitiveness, to reduce costs or to
increase revenue, to satisfy regulatory requirements, and to generally improve the user
experience.
? plays a significant role in the distribution of data from disparate sources throughout the enterprise
in real-time, thereby facilitating the implementation of RTBI capabilities.
11
.
Shadowbase Real-Time Business Intelligence Case Studies
Shadowbase solutions are used extensively to provide real-time business intelligence to a variety of
enterprises. Some examples of these applications and how it is being used to improve business services,
company competitiveness, and profitability are shown in the case studies below.
Fraud Detection
ATM and point-of-sale (POS) devices are typically managed by a local servicing bank. However, this bank is
likely not the bank that issued the credit or debit card used at the device. A major provider of interbank
electronic transaction switching services for ATM and POS terminals routes each credit card transaction from
the servicing bank to the bank that issued the credit card. The issuing bank then returns an authorization or a
rejection to the credit card terminal via the provider’s switching system and the servicing bank.
If the transaction switch fails, no credit card transactions are accepted by the terminals that the transaction
switch provider services. The provider uses an active/active, geographically distributed system comprising HP
NonStop nodes to provide extreme reliability for its transaction message switch (Figure 15). Shadowbase bi-
directional replication is used to keep the databases of the active/active nodes in synchronization.
For more information, please see the Gravic white papers, Shadowbase Streams for Data Integration and Shadowbase Streams
for Application Integration.
Gravic, Inc. White Paper
The Evolution of Real-Time Business Intelligence and How to Achieve it Using Gravic Shadowbase
®
Page 28 of 33
As an additional service to the credit card companies that are its customers, the provider offers fraud detection.
Credit card transactions captured by its HP NonStop servers use the Shadowbase data replication engine on
a Solaris server running Oracle. The credit card transactions are transformed by Shadowbase replication to
the format required by the Oracle database. Complex queries are run against the Oracle database to monitor
card activity for suspected fraudulent activities.
If a suspected fraudulent transaction is detected, an indication of this transaction is immediately returned via
Shadowbase replication to the HP NonStop switch for forwarding to the issuing bank. The issuing bank can
elect to reject the transaction and deactivate the card or to allow the transaction.
This case study is an excellent example of real-time business intelligence at work. The Solaris system is an
RTBI system and maintains a history of credit card usage for each credit card and uses the current credit card
transaction data to deduce the possibility of fraud. If fraud is suspected, this suspicion is communicated in real-
time to the issuing bank for immediate action, potentially saving the company thousands of dollars in fraudulent
transactions.
Investment Product Promotion
A provider of stock trade execution services provides real-time business intelligence systems to its brokerage
customers. The brokerages use this RTBI system to monitor the trading activity of their individual customers
to determine possible investment products in which their customers might be interested.
The execution service provider uses an HP NonStop system to execute trades submitted to it by its brokerage
customers (Figure 16). It sends customer trade requests to the appropriate exchange floor for execution and
returns execution reports to the brokerage firm. Connections between the brokerage firm system and the
execution system are provided by the Shadowbase data replication engine.
Shadowbase
S
h
a
d
o
w
b
a
s
e
S
h
a
d
o
w
b
a
s
e
RTBI ATM
Fraud Detection
Solaris Oracle
NonStop NonStop
Active/Active
Transaction Switch
Issuing
Banks
Servicing
Bank
Servicing
Bank
ATM POS
Figure 15 - Real-Time Business Intelligence for Fraud Detection
Gravic, Inc. White Paper
The Evolution of Real-Time Business Intelligence and How to Achieve it Using Gravic Shadowbase
®
Page 29 of 33
The execution service provider supplies a back office system to its brokerage firms to handle trade accounting
and position management. This system also has an RTBI component for monitoring customer activity.
Individual customers enter their trade requests via the Internet into the brokerage firm’s back office accounting
system. Each trade request is forwarded to the execution service provider for execution. The execution report
is returned to the customer by the brokerage firm and is used to update the customer’s position and trading
activity in the back office accounting system.
The RTBI subsystem resident in the back office system continually monitors the customer’s portfolio position
and trading activity. It analyzes the risk tolerance exhibited by the customer through his activity and, along with
the customer’s age and other information, determines if investment products provided by the brokerage firm
might be of interest to the customer. If so, information on those products is sent to the customer while he is
online. This case study is an example of an RTBI system using real-time events to determine potential
marketing opportunities, thereby increasing revenues.
Tactical Reordering and Strategic Marketing
A major North American independent distributor represents more than three million parts critical to the
operations of maintenance, repair, and overhaul (MRO) and original equipment manufacturer (OEM)
customers in virtually every industry. It also provides engineering, design, and systems integration for industrial
and fluid-power applications as well as customized mechanical, fabricated rubber and fluid-power shop
services.
S
h
a
d
o
w
b
a
s
e
S
h
a
d
o
w
b
a
s
e
Internet
Exchange
Floor
Trade
Executions
NonStop
Execution System
RTBI functions
Age
Portfolio Position
Trade Activity
Risk Tolerance
Back-Office
Accounting System
Customer
Trading Activity
Investment Product
Promotions
Trades Executions
Figure 16 - Investment Product Promotion
Gravic, Inc. White Paper
The Evolution of Real-Time Business Intelligence and How to Achieve it Using Gravic Shadowbase
®
Page 30 of 33
Its network encompasses more than 4,600 associates at 445 facilities in the continental United States, five
Canadian provinces, Puerto Rico, and Mexico. Its seven strategically located distribution centers warehouse
millions of dollars of inventory to support its local service centers and customers with necessary products. The
distributor uses an HP NonStop server to accept orders from its customers and to fulfill these orders (Figure
17).
To better improve operations, the distributor implemented a real-time business intelligence system running
under Windows SQL Server. This system is driven by order information from the HP NonStop order-entry
system delivered via a Shadowbase data replication engine. The RTBI system maintains a database of order
history and current orders.
Using the order history and analytic strategic processing, the distributor determines what marketing services
will be the most effective to grow its business (a strategic data warehouse function). Using current order activity,
it determines in real-time when parts need to be reordered (a tactical RTBI function). This case study is an
example of feeding an RTBI system that supports both strategic analytics and tactical responses to current
events in order to increase revenues and improve customer satisfaction.
Travel Analysis and Profiling
One of Europe’s leading providers of tours and packaged travel offers an expansive array of flights, hotels,
package tours, flexi-packages and independent holidays to travel agencies and several million consumers
throughout Europe. Its travel brand offers flexible and fixed vacation packages to major leisure destinations
worldwide. It supports hundreds of travel agents with an HP NonStop server system.
One of the provider’s services is to offer discount coupons to its clients for frequently traveled routes and
destinations. To determine the applicability of coupons for various itineraries, it uses a real-time business
intelligence system to track travel patterns and volumes.
This business intelligence system runs on a Windows SQL Server (Figure 18) and uses online analytical
processing to discover travel patterns of potential candidates for coupons. Travel data from its HP NonStop
server is sent in real-time via the Shadowbase data replication engine to the business-intelligence system as
the provider’s travel agents book travel and accommodations for their clients. Using this architecture, the
company determines in near real-time appropriate travel patterns, and then offers timely travel and leisure
discount coupons to its clientele, for increasing revenue generation.
Windows SQL Server
Marketing Services
Shadowbase
NonStop Server
Order Entry
RTBI Current Order Database Order Processing
Trickle Feed
Strategic
Analysis
RTBI
Reorder
Figure 17 - Real-Time Business Intelligence for Parts Distribution
Gravic, Inc. White Paper
The Evolution of Real-Time Business Intelligence and How to Achieve it Using Gravic Shadowbase
®
Page 31 of 33
Summary
The speed of today’s processing systems has moved classical data warehousing into the realm of real-time.
The result is real-time business intelligence. Business transactions as they occur are fed to a real-time
business intelligence system that maintains the current state of the enterprise. The RTBI system not only
supports the classic strategic functions of data warehousing for deriving information and knowledge from past
enterprise activity, but also provides real-time tactical support to drive enterprise actions that react immediately
to events as they occur. It replaces both the classic data warehouse and the enterprise application integration
functions. Such event-driven processing is a basic tenet of real-time business intelligence.
The Shadowbase suite of products provides the capabilities necessary to integrate disparate operational
application information into the RTBI system and to support the functions of real-time business intelligence.
The Shadowbase replication engine is a high-speed, bi-directional, heterogeneous data replication engine that
moves data updates from enterprise systems to the RTBI system and back in fractions of a second. It allows
the events to be filtered and transformed into formats that downstream processing can utilize, allowing for
embedding complex processing rules into the replication engine instead of having to encode them into the
applications themselves. It supports active/active configurations for RTBI systems to achieve extreme
availability.
With real-time business intelligence, an enterprise establishes long-term strategies to optimize its operations
while at the same time reacting with intelligence to events as they occur. Shadowbase software provides
companies the suite of products necessary to leverage this RTBI technology with proven implementations,
while providing significant business benefits.
Windows SQL Server
Client Services
Shadowbase
NonStop Server
Reservations
Agents
Travel Data
RTBI Coupon Travel
Pattern Analysis
Figure 18 - Real-Time Business Intelligence for Travel Packaging
The Evolution of Real-Time Business Intelligence and How to Achieve it Using Gravic Shadowbase
®
Gravic, Inc. White Paper Page 28 of 33
Gravic, Inc. Contact Information
17 General Warren Blvd.
Malvern, PA 19355-1245
USA
Tel: +1.610.647.6250
Fax: +1.610.647.7958
www.gravic.com/shadowbase
Email Sales: [email protected]
Email Support: [email protected]
International Distributor Information
Global
Hewlett-Packard NonStop Enterprise Division
1501 Page Mill Road #1429
Palo Alto, CA 94304-1100
USA
Tel: +1.408.691.2908
www.hp.com
Europe
Hewlett-Packard Nederland BV
Startbaan 16
Amstelveen 1187 XR
The Netherlands
Tel: +31 20 547 6911
Fax: +31 20 547 7755
www.hp.nl
Africa
Business Connexion (Pty) Ltd
Business Connexion Park
789 16th Road
Randjiespark
Midrand
South Africa
Tel: +27 (0)11 653 5365
www.bcx.co.za
Asia Pacific
Legato Solutions & Services Pte Ltd
10 Ubi Crescent
#04-65 Ubi TechPark
Singapore 408564
Tel: +65 68463 150
Fax: +65 67489 356
www.legato.com.sg
Japan
High Availability Systems Co. Ltd
MS Shibaura Bldg.
4-13-23 Shibaura
Minato-ku, Tokyo 108-0023
Japan
Tel: +81 3 5730 8870
Fax: +81 3 5730 8629
www.ha-sys.co.jp
Gravic, Inc. White Paper
The Evolution of Real-Time Business Intelligence and How to Achieve it Using Gravic Shadowbase
®
Page 29 of 33
Breaking the Availability Barrier Book Series
Breaking the Availability Barrier, Survivable Systems for Enterprise Computing
Volume I describes the techniques that can be used today for extending the time
between system failures from years to centuries, often at little or no additional cost.
For More Information.
Breaking the Availability Barrier, Volume II, Achieving Century Uptimes with
Active/Active Systems
Volume II extends the theoretical topics covered in Volume I and covers significant
issues and technologies related to active/active architectures, including availability
calculations, redundant reliable networks, distributed databases, TCO, and node
failures.
For More Information.
Breaking the Availability Barrier, Volume III, Active/Active Systems in Practice
Volume III is a companion to Volume II and contains practical examples and case studies
for actually building active/active systems based upon the principles covered in Volumes
I and II.
For more information.
The authors of this series, Dr. Bill Highleyman, Paul J. Holenstein, and Dr. Bruce D. Holenstein, have a
combined experience of over 100 years in the implementation of fault-tolerant, highly available computing
systems. This experience ranges from the early days of custom redundant systems to today’s fault-tolerant
offerings from HP (NonStop) and Stratus. Learn more about the authors. These books can be ordered from
www.authorhouse.com or www.amazon.com. For white papers, case studies, datasheets, and more
information, please visit www.gravic.com/shadowbase/whitepapers.
For further information about Shadowbase solutions and how they enable active/active replication
architectures or are used to solve other business problems, such as feeding a data warehouse with real-time
data, contact Gravic at +1.610.647.6250, [email protected], or visit our website at
www.gravic.com/shadowbase.
About Gravic, Inc.
Gravic, Inc. is a privately-held corporation located in Malvern, PA, about twenty miles west of Philadelphia, PA, USA. Gravic makes a
number of computer software products for data collection, transformation, and distribution uses. Customers of its Shadowbase data
replication and data integration products include banks, financial and brokerage firms, insurance companies, stock exchanges, electric
utilities, healthcare, and telecommunications companies.
Copyright and Trademark Information
This document is Copyright © 2014 by Gravic, Inc. Gravic, Shadowbase and Total Replication Solutions are registered trademarks of
Gravic, Inc. All other brand and product names are the trademarks or registered trademarks of their respective owners. Specifications
subject to change without notice.
doc_621830239.pdf