Example 6: When to use a Virtual ODS
A real-time, virtual ODS is possible through the use of virtual data
federation. For this, EII technology is used to directly access data in
the operational systems. There are certain conditions that should
be met before a virtual ODS makes sense. These are:
- Operational need for real-time, not near real-time, data – The
business users have a mandatory and demonstrable
requirement for integrated, current data. Compliance,
customer satisfaction, and just-in-time inventory are just a few
of the drivers behind this need for real-time data.
- Fairly well-integrated operational data – The amount of
integration and quality processing that can be done “on the
fly” is limited so source data for the virtual ODS should be in
good shape to begin with. An example of this characteristic
would be data from multiple instances of an ERP application
such as SAP’s R3. The data exists in the same format,
meaning, and usage – it just resides in multiple places.
- Narrow queries – EII’s high performance query processing
works best when the federated queries are specific in nature.
They should focus on a small or limited amount of data
returning an equally limited amount of data. Generally the
ODS is used to examine a few records – e.g., a customer’s
current transactions or a product’s worldwide inventory level.
- Unpredictable queries – Operational BI needs and data are
quite varied – e.g. a customer’s last five shipments are
needed, next their last ten invoices, and then, their last three
returns. A virtual ODS can easily meet these diverse and
unpredictable operational requirements.
The advantages of a virtual ODS can be significant:
- Short time to solution - A virtual ODS is quite useful when there
is a short fuse on the need to access of operational data.
Access can be implemented in a matter of hours or, at most
a day or two.
- Frequent change – If changes in requirements are constantly
requested, the ability to quickly rework the data presentation
is a great way to ensure user satisfaction. The agility of the
enterprise places a high premium upon this form of ODS.
- Security or privacy issues prevent replication of data – The
need to access integrated data may be mandatory but the
ability to create a physical ODS may be prohibited due to
security, regulatory, or other issues.
Example 7: When to use a Physical ODS
A virtual ODS not make sense when the data volumes requested
are too high, the integration and quality issues cannot be resolved
at run time, and the performance of the underlying operational
systems becomes compromised. A physical ODS is mandatory
under these circumstances:
- Complex data integration processing – A physical ODS may
be the only place where a current “360 degree view” of
important enterprise entities such as customer or product can
exist. Many CRM projects used the ODS as the cornerstone
for understanding an enterprise’s customers. If this data
requires considerable integration processing, data
consolidation using traditional ETL technology is required.
- Extensive data quality processing – Similar to the data
integration situation, many corporations must perform
considerable name and address matching and hygiene
along with house-holding processes before the customer
data is usable. If this is the case, then a permanent, physical
ODS is recommended.
- Access by high numbers of users – If the ODS is to be made
available to every frontline employee in an organization, its
performance must be the principal driver and this access
must not impact the operational systems performing their
daily tasks. In this case, IT should construct a physical ODS.
Of course, there are some drawbacks to a physical ODS as well:
- Data latency – A physical ODS usually does not contain realtime
data; the data has some latency due to the data
consolidation processes performed. This latency can be from
a few seconds in duration up to 24 hours depending on the
state of the operational environment, business users’
requirements, and the maturity of the data integration and
quality infrastructure.
- Potential performance problems – If the ODS is used for
management reporting, operational look-ups, and BI
analytics, it must be closely monitored to detect potential
and real performance issues. Such a mixed workload can
impact response times unless the ODS is implemented with
appropriate indexing schemes, partitioning, etc.
Operational BI Integration Examples
Operational BI is the newest form of BI adopted by enterprises. It is
meant to support operational decision-making by combining the results
from strategic analyses with real-time and low-latency sources of data.
A formal definition is:
Operational BI is a set of services, applications and
technologies for monitoring, reporting on, analyzing and
managing the business performance of an organization’s daily
business operations.
Operational BI is used by line of business managers, front line employees
and even operational processes to manage and optimize daily business
operations. Its goal is to compress the time latency between knowing
when an important business event has occurred and taking action in
response to it. To be optimal, operational BI relies on the continuous
availability of operational data and analytical results.
Example 8: The Need for Multiple Data Sources for
Operational BI
The need to combine multiple, disparate sources of data in support
of operational BI makes a great case for virtual data federation.
The sources of data for operational BI include the operational
systems, operational data store, and traditional BI analytics from the
data warehouse and/or data marts. From the point of view of the
applications and business users, the data should appear as if it were
in a single, seamless store of data. Of course, in reality, the data
hasn’t been moved at all – it still resides in its original locations.