Hi All,
Recently i have heard a lot about this topic of BI as service so here is some common example and their use
Consider a system detecting
retail fraud. In BI we have the tools to build an analytical engine capable of
mining the potentially huge amounts of transactional data for patterns
resulting in a list of suspicious credit cards. The adoption of SO principles
allows us to offer a service providing the details of credit cards in use in
our store as they are swiped. The SoBI architecture allows this service to be consumed by the BI
component of the platform and analyze it against the known list of suspicious
cards, and therefore to respond immediately should a potentially suspicious
transaction be detected….. Very good Example. It allows applications to
use BI in real time
Why this needs to be service. Why not directly write a sql on datawarehouse from the Java/.net Application.
A simple case would be the
application developers does not need to know the logic for implemneting the DW checks, The maintance
is easy no code change needs to be done in the application as service code can
be changed any time without application downtime
Uses of Services in Business intelligence
Aggregation of transactional and historical data as a
service. Given a service exposed through the SoBI framework that can now
seamlessly aggregate current transactional data and historical warehouse data,
a new breed of business services can be supported. An example would be slowly
changing dimensions, which is where a value such as a customer name changes
over time. Obviously this information is available within the data warehouse,
so if there is a requirement to expose an entity service that gives a single
view of the customer, this can be achieved more accurately and easily.
Brings
interface abstraction patterns to BI. The ability to use the interface
abstraction pattern over BI functionality makes the functionality and data more
accessible to line-of-business applications and provides the capability to
expose complex business rules usually buried in the ETL layer.
My note - You can keep master data management.
Where in datawarehouse you have a single truth of data that is cleaned like
addreess of customer that can be requested as service from application
Cleansing and consolidation. Data will be
changed for purposes of consistency and integrity. Where this change involves a
mapping operation, that mapping will be made available to the architecture as a
service. Where this change involves a correction to data, details of that correction
will be fed back to the system of record through a request for change to the
owning service, that is, the ETL process cannot change the data as it is not
the owner. In turn, this process obviously drives improvement in the quality of
data.
Obtain a cross-system, consistent view of the product.
During the ETL stage data of the same product (or entity) may require
transforming in order that it may be stored in a consistent manner. By service
enabling access to the data the organization can expose a single common view of
a product.
Mappings available as a service. As previously
stated, mapping is a fundamental requirement within the ETL stage. The SoBI
framework enables the mapping functionality to be exposed as a service for
other uses within the organization. Such uses include EAI and enterprise
reference scenarios. This availability of this service can also be used to
promote best of breed transformations.
Calculation. The data warehouse is often used
to store precalculated values to support the requirements of BI. For instance,
sales and forecasting data may be held in different physical systems. The
consolidation of the data from these systems into the data warehouse allows us
to calculate and store actual versus forecast figures to support more
performant analysis and reporting. The business logic used to define such
calculations is often interesting to other parts of the business so the
calculation to support this invention of data in the data warehouse will be
made available to the SoBI architecture as a service.
Aggregation. To support fast response times,
data in the data warehouse is often preaggregated. For instance, the data
warehouse may contain data relating to sales at an individual transaction
level, but the majority of management reporting may require seeing the totals
at the month level. In this case, it is cost effective to roll the (potentially
millions of) individual transactions up to a level more appropriate for the
known queries and to store the results in an aggregation, avoiding the need for
known queries to perform the aggregation action at query time. Where such
aggregations are created, they will be made available to the architecture as a
service.
Provides a road map for integration. It is
believed that one of the outcomes for the SoBI framework is an ability, at an
architectural level, to provide a framework for future integration scenarios.
Compliance/audit. Application of the SoBI
framework requires adherence to a formal governance process. Examples include
the identification of the system of record or operational data owner, and the
definition of the messages that describe the data and functional requirements.
Given only the owner of the data can make a change to that data, other systems
simply make a request for change, and auditing can be carried out at a single
point.
