« March 2008 | Main | May 2008 »
April 19, 2008
BI Strategy Definition - A "First Principles" Approach
Business Intelligence (BI) Strategy definition is typically the first step in an organization's endeavor to implement BI. This phase is very crucial as the overall execution direction hinges on decisions taken in this stage.
A practical approach to BI Strategy definition includes the following steps:
1. Business Area Identification - Identify and prioritize the business area(s) for which BI is considered. Ex: Human Resource Analytics, Supply Chain Analytics, Enterprise Performance Analytics etc.
2. Process Mapping Document - Once the business area is identified, map out the individual processes involved in that particular domain. This can be a simple flow-chart that shows the entry and exit criteria for each sub-process.
3. Business Questions Enumeration - Based on the subject areas involved in the business domain, enumerate the list of questions that are to be answered by the analytical layer.
4. Data Elements Segregation - For each of the process steps, identify the data elements. These data elements, after subsequent validation (in conjunction with business questions) would translate into dimensions and facts during the data modeling stage.
5. Data Visualization - Develop a prototype (set of screenshots) on how the data would be visualized for each business question. Business Analysts and domain experts are typically involved at this stage.
6. BI Architecture Synopsis - At a fundamental level, BI architecture is fairly straightforward. The architecture is almost always a combination of the following processes: Extraction (E), Transformation (T), Loading (L), Cubing (C), and Analyze (Z). The number of layers, type of reporting etc. are a combination of ETLCZ components. Ex: ETLZ, ETLTLCZ, ELTZ, ELCZ are some options for BI architecture definition.
7. Next Steps Document - The 'Next Steps' document would list down the other requirements of / from the analytical infrastructure. These can be points around Tool Evaluation, User profiles, Data volumes, Performance considerations, etc. Each of these requirements would translate to an assessment to be carried out before the actual construction begins.
The most common mistake is to start thinking about technology aspects before the actual business requirement is finalized. A precise definition of business questions goes a long way in designing a scalable and robust BI infrastructure.
Posted by Karthikeyan Sankaran at 11:45 PM | Comments (3)
April 13, 2008
Metadata in the BI World
For as long as I can remember, the definition given for Metadata is "Data about Data".
We have all said this in interviews, heard it from candidates, seen it on presentations and have (almost) always nodded our heads in agreement. In the transaction processing world, where "data-in" is the paradigm, the definition is precise. The databases store the business data in the relational format and the system tables / catalogs describe the structure of that data - the columns, type, size, etc. This data about the structure of business data is "Metadata".
In the Business Intelligence world, that definition of metadata is incomplete. A more precise definition of metadata has two components:
Metadata in BI = "Data about data" plus "Information about information".
The first component "Data about data" is "Technical Metadata" and is similar to the metadata in the OLTP world. Having said that, the technical metadata in BI is arguably more complex, as it not only encompasses the databases but needs to cover the ETL and Reporting tools as well. Each of the tools in the overall BI landscape has its own metadata and this data has to be looked at in a comprehensive fashion to understand data lineage etc.
Even among BI tools, there are different categories - Tools that expose its metadata completely, tools that gives an handle to its metadata through pre-defined APIs and tools that do not allow any access to the metadata. Given the industry direction and the evolution of Common Warehouse Metamodel (CWM) compliance standards, it is only a matter of time before the tool architecture is designed to expose the technical metadata. CWM is a fascinating topic of its own and you can get a feel for it by visiting this website: http://www.omg.org/technology/cwm/
To me, as a BI practitioner, the second piece of the metadata puzzle is the more interesting part. "Information about information" aspect of metadata is "Business Metadata" and its understanding is crucial to implementing the BI vision in any enterprise.
As an analytical information consumer, I have 2 important questions:
1) Need direction to access the required analytical content. Examples are:
a) Where can I get Sales by Product for different geographies over the last 2 years?
b) I am interested in Customer Churn Analytics. Now where do I go? ("system"ically speaking!)
2) Once the content is retrieved, need guidance on how to make sense of it. Examples are:
a) I see the Forecasted Sales for next quarter in the chart. How is this value calculated?
b) Total Inventory value shown in this report ? does it include the Raw material inventory or excludes it?
To the analytics provider, this is a complex problem that cuts across Knowledge Management and context based search disciplines. Having said that, it is important for BI practitioners to understand the true nature of business metadata and provide implementable solutions in their specific organizational context.
I would discuss this fascinating area of Metadata management, encompassing both technical and business metadata, in my future posts.
Please do keep reading and share your thoughts as well.
Posted by Karthikeyan Sankaran at 6:45 AM | Comments (2)
April 5, 2008
Business Intelligence @ Crossroads
Business Intelligence (BI) is well & truly at crossroads and so are BI practitioners like me. On one hand there is tremendous improvement in BI tools and techniques almost on a daily basis but on the other hand there is still a big expectation gap among business users on Business Intelligence's usage/value to drive core business decisions. This results in every BI practitioner developing a 'split' personality - a la Jekyll and Hyde, getting fascinated by the awesome power of databases, smart techniques in data integration tools, reporting etc. and the very next moment getting into trouble with a business user on why 'that' particular metric cannot be captured in an analytical report.
For the BI technologists, there is never going to be a dull moment in the near future. With all the big product vendors like Microsoft, Oracle, SAP, IBM etc. throwing their might behind BI with their acquisitions and product development and BI specialty providers like Informatica, SAS et al. showing no signs of slowing down - "the technologists can get ready to join the big swinging party"
For the business users, there is still the promise of BI that is very enticing - 'Data to Information to Knowledge to Actions that drive business decisions'. But they are not giving the verdict as of now. Operational folks are really not getting anything out of BI right now (did somebody say BI 2.0?) and the strategic thinkers are not completely satisfied with what they get to see.
The techno-functional managers, the split personality types are the ones in the middle trying to grapple with increasing complexity on the technology side and the ever increasing clamor for insights from the business side.
Having said that, Business Intelligence is so interesting as it presents a wide canvas for practitioners to paint their strokes. These can be related to business domains, technology (databases/tools/web etc.), statistics, visualization, project management and most importantly "common sense".
Pick your strokes right away - there is more coming from this space on the fascinating world of Business Intelligence.
Have a great day! Thanks for reading.
Posted by Karthikeyan Sankaran at 5:30 AM | Comments (0)
