The most complex thing to keep up to date in any Business Intelligence Application environment is the Knowledge of Business logics. Not only the logics behind the codes, but documenting the reasons behind decisions is also essential to avoid trotting on petabytes of data later.
Often, Organizations use Word or Excel based documents for Knowledge Management. These artifacts will have usually a defined set of owners identified who alone can edit. This method will work well if the documentations are well maintained and kept up to date. However, the volume of logics that get implemented and changed with business changes are huge in BI environment and not every detail gets into the documents.
In some decade plus old DWH environments knowledge exists as part of the "Inicidents" in ticket management system if ITIL based service management tools are used. Searching through the tickets to find business logics is certainly not pleasurable. Since all the Business Logics weren't existing in structured manner, resolving incidents would take longer time and it wastes energy.
In such cases, documenting all the knowledge from scratch using the fragmented sources such as Incident details will be difficult and may take years. The easiest approach in such cases is to opt for Collaborative knowledge gathering as a continual process.
Setup a structure such as wiki for such collaborative knowledge gathering. People can add in knowledge as and when they find time during the course of the maintenance activities.
Business Intelligence applications need the following kind of documentation the least.
- Source Details (Source table or file name, content structure, field level details, applicable values, periodicity of data availability, mode of transfer such as ftp push/pull)
- Every table in DWH (and other DB objects such as views, procedures, etc.) should have adequate details about the business use, loading frequency, sources used to load the data, etc.
- Every field of a table need to have the following details: business use, logic used to load the field, valid values, historical decisions behind the logics used, the fixes done, etc.
- Business report details (who uses that, how important is that to business, what are the verifications that need to be done, etc.)
Create a structure (template) to capture the details relevant to the BI implementation. Collaborative Knowledge Management for DWH may be the easiest and cheapest way to realize efficiency.
Often, Organizations use Word or Excel based documents for Knowledge Management. These artifacts will have usually a defined set of owners identified who alone can edit. This method will work well if the documentations are well maintained and kept up to date. However, the volume of logics that get implemented and changed with business changes are huge in BI environment and not every detail gets into the documents.
In some decade plus old DWH environments knowledge exists as part of the "Inicidents" in ticket management system if ITIL based service management tools are used. Searching through the tickets to find business logics is certainly not pleasurable. Since all the Business Logics weren't existing in structured manner, resolving incidents would take longer time and it wastes energy.
In such cases, documenting all the knowledge from scratch using the fragmented sources such as Incident details will be difficult and may take years. The easiest approach in such cases is to opt for Collaborative knowledge gathering as a continual process.
Setup a structure such as wiki for such collaborative knowledge gathering. People can add in knowledge as and when they find time during the course of the maintenance activities.
Business Intelligence applications need the following kind of documentation the least.
- Source Details (Source table or file name, content structure, field level details, applicable values, periodicity of data availability, mode of transfer such as ftp push/pull)
- Every table in DWH (and other DB objects such as views, procedures, etc.) should have adequate details about the business use, loading frequency, sources used to load the data, etc.
- Every field of a table need to have the following details: business use, logic used to load the field, valid values, historical decisions behind the logics used, the fixes done, etc.
- Business report details (who uses that, how important is that to business, what are the verifications that need to be done, etc.)
Create a structure (template) to capture the details relevant to the BI implementation. Collaborative Knowledge Management for DWH may be the easiest and cheapest way to realize efficiency.
No comments:
Post a Comment