|
An operational data store (ODS) is a
database designed to integrate data
from multiple sources to facilitate
operations, analysis and potentially
reporting. Because the data
originates from multiple sources,
the integration often involves
cleaning, redundancy resolution and
business rule enforcement. An ODS is
usually designed to contain low
level or atomic (indivisible) data
such as transactions and prices as
opposed to aggregated or summarised
data such as net contributions.
As part of the Information and
Data Modelling approach offered by
Lonispace we are often required to
deploy an ODS to ensure a level of
transparency, audit and replay
functions for the solution being
implemented. Some examples of use
for an ODS are; what is the complete
credit position of a customer across
the entire business, how can we
provide a consolidated view of all
products and transactions, how can
we detect credit card fraud while
the transaction is in progress and
what is the current consolidated
profitability status of a customer?
Each business challenge fitting
the ODS model should be categorised
by subject area, prioritised by the
business and then split into
manageable projects. The ODS
architecture should be constantly
re-evaluated, taking into account
the current and future evolutions of
the business environment.
There are three principle ODS
architectures, that are
differentiated by the level of
integration between the operational
systems and the ODS. In practice,
most often hybrids of the three
architectures are used; real time
store and forward or batch, real
time store and forward or batch
trigger and apply updates and real
time update and access fully
integrated. The data elements
flowing to the ODS must be carefully
constrained to simplify the design
and increase the chances of a
successful implementation. Only
populate the ODS with data required
by the modelled subject area and
dictated by business requirements.
For some data elements (such as
address) the business may decide
that the ODS will become the system
of record. In these cases business rules will have to be defined for updates to the ODS (perhaps managed
by a RDM system) not initiated by an
ODS end-user. These rules will
decide which data should overwrite
the ODS system of record. If the ODS
is not the system of record, then
the same types of business rules
will have to be developed for the
trigger mechanism. In this instance
the data sources may be the system
of record.
The ODS data model can be derived
from the enterprise Common Data
Model (CDM). Typically the
enterprise CDM describes all data
which is needed for corporate
information purposes. The ODS data
model is normally a subset of the
enterprise CDM. Only those parts
which are required are taken for the
ODS data model. As with the CDM our
focus is on the structure of the
data for representation not the
content.
Organisations wishing to
integrate large amounts of complex
and fragmented operational data need
to capture the source data to
populate the ODS in order to meet
their business objectives. In our
approach to ODS Lonispace concerns
itself with the ODS data
characteristics that is subject
oriented, integrated with multiple
operational sources, current valued, and detailed. In selecting
operational data for the ODS
deployment, points to consider are:
- Identify the core business
requirements to provide the ODS
scope and begin the business logic
and data modelling review
- Synchronise the ODS data model
with the corporate CDM
- Develop the ODS high level design
to verify the scope and methodology
deployed
- Document high level solution
design and ensure all necessary
components are identified
- Determine costs, benefits, and
sizing using the solution’s design
- Identify system records and
determine which is the single
version of truth for each.
- Identify the operational sources
for ODS.
The extract and capture component
must have minimal impact on the
design and architecture of the data
sources. Because of the operational
nature of an ODS, this component
must be highly reliable and be able
to scale in size. While the
build/transform component is
responsible for preparing the
extracted data for populating the
ODS. This component executes data
transformations such as cleansing,
aggregating, de-normalising,
reconciling, consolidating, and
formatting or a combination of these
functions in real-time or near
real-time. Please read our white
paper on Information and Data
Modelling for more information about
these subjects.
Lonispace highly recommends the Asset Control range of products combined with TIBCO's real time Integration product suite (Active Matrix BusinessWorks) for all MDM applications in the financial services market. We have attached document overviews of Asset Control’s two offerings AC+ and TAPMaster, however if you require more in depth information please contact us by phone or email at info@lonispace.com.au or you can enter the Asset Control and TIBCO websites and register, to gain access to their brochures, news articles and whitepapers on data and information integration for the financial services market. –see attached brochures for Asset Control's AC+ and TAPMaster.
|
