Welcome to our blog. This is an archived post, most of our knowledge and advice remain valid but some material or links may be outdated. Click here to see our most recent posts.
This is the seventh blogpost in the Data Management series. After having covered basic terminology and key Data Management functions such as Master Data Mangement and Meta Data, we now zoom in on the field of Business Intelligence:
Business Intelligence (BI) is a very broad subject with many different interpretations. In fact, it is hard to conceive a discipline related to data management with a more controversial definition. Following the work of David Loshin, we define Business Intelligence as follows:
The process, technologies, and tools needed to turn data into information, information into knowledge, and knowledge into plans that drive profitable business action. Business intelligence encompasses data warehousing, business analytic tools, and content/ knowledge management
Unfortunately it is often seen as a technical discipline while in fact (as the cited definition shows)it is a set of business capabilities involving things like:
Query, analysis, and reporting activity by knowledge workers to monitor and understand the financial operation health of, and make business decisions about, the enterprise.
Query, analysis, and reporting processes and procedures.
Strategic and operational analytics and reporting on corporate operational data to support business decisions, risk management, and compliance.
The key characteristic for Business Intelligence is that it typically involves aggregated/ historical data. These are often managed from a(n enterprise) data warehouse, abbreviated with EDW, which is a central repository of data which is created by integrating data from one or more disparate sources.
Typically users do not interact directly with this EDW. Instead, specialized environments tailored to specific information needs of end users are built on top of it such as data marts, analytical workspaces, OLAP cubes etcetera.
A data mart is the access layer of the data warehouse environment that is used to get data out to the users. The data mart is a subset of the data warehouse that is usually oriented to a specific business line or team.
One of the interesting aspects of these environments is that they are modeled in different ways, e.g.:
Type of system
Typical ways of modeling
Relational, hierarchical (e.g. XML)
Data Vault, dimensional, normalized
Each of the ways of modeling has their own distinct advantages and disadvantages. Regardless of the way of modeling, just like in Master Data Management (See our previous blogpost in this series) the lineage and flow of data is what’s key.
It should be noted that the field of BI is strongly related to other fields covered in this series:
In Business Intelligence, the adage “garbage in, garbage out” is particularly true. It is often crucial to have historic information of crucial business objects. This puts Master Data Management in the middle of the business intelligence spotlight!
Keeping track of where data comes from, how it was modified (e.g., to clean it or aggregate it in an EDW), who needs it, who is responsible for it etcetera is key for being able to manage and prove the quality of data from intelligence platforms
The role of the data steward – the person responsible for data quality frm a business perspective – is equally important for regular systems as it is for Business Intelligence-systems such as an EDW or Data Mart.
In terms of modeling the field of Business Intelligence is not very spectacular. Business Intelligence systems are modeled similar to ‘normal’ systems (i.e., transaction systems such as your favorite ERP or CRM system). That is, we use the ApplicationComponent concept. However, given the relative importance of Business Intelligence-related systems for keeping the enterprise running efficiently and effectively, it makes sense to visualize them differently. Most modern tools like BiZZdesign Enterprise Studio allows you to either change the shape of a single concept, or use profiles to consistently change the visualization of all concepts that have this profile.
Along the same line of reasoning, it makes sense to distinguish data (historic, aggregated) that comes from Business Intelligence systems from ‘normal’ data using the DataObject concept.
Most of the other relevant aspects are already covered by the modeling aspects for Master Data Management (See our previous blogpost in this series): aggregation of Data Objects in Business Intelligence Systems is done using the AggregationRelation, if necessary with a profile to distinguish it from a regular aggregations.
In terms of communication: many stakeholders prefer tabular / matrix representations of key aspects of a data architecture over graphical models. Most tools allow the generation of matrices. Examples would be:
Show business processes (columns) related to Business Intelligence systems (rows) with names of the Business Intelligence data that is used in the process (DataObject) on the intersection
Similar, but with stakeholders (BusinessRole or BusinessActor) rather than processes on the columns
A data flow matrix, showing how data (DataObject) flows from one system (ApplicationComponent) to another
Remember: modeling is about communication as much as analysis and design!
SUBSCRIBE TO BIZZDESIGN'S BLOG
Join 10.000+ others! Get BiZZdesign's latest articles straight to your inbox. Enter your email address below: