• Blog
  • BI Platform
  • Organizing Content in a Business Intelligence Platform Using a Numbering System
Wednesday, 20 February 2013 09:15

Organizing Content in a Business Intelligence Platform Using a Numbering System

Written by
Rate this item
(0 votes)

Today, most organizations actively use some sort of Business Intelligence platform to manage the access and delivery of intelligence to executives, knowledge workers and front-line staff to enable them to perform their jobs. BI platforms have been around for a long time. Some organizations have gone through major conversions from previous legacy systems to adopt modern platforms while others had the luxury of starting from scratch with brand new 'empty' platforms. Whatever the scenario, BI is key to intelligence delivery and productivity.


What kinds of content does a BI platform hold? Reports, dashboards, OLAP Cubes, ad-hoc queries, documents of all types (PDFs, Word Docs etc...), executables (Java or batch programs), event triggers (file or schedule-based for conditionally kicking off processes)... Most companies start developing and delivering the most pressing analytic content - reports or cubes - based on some priority matrix (a mix of feasibility vs business value), and more often than not, little time is spent planning up front how to maintain and organize the massive amount of BI content that the organization soon becomes hooked on.

Most BI analytic solutions are developed, tested, approved and deployed to the BI platform using generic names, for example, 'Accounts Receivables Report' or 'Actuals vs. Budget Cube'. While such names are great for giving busines users an idea of the type of content that will be presented within the analytic, more often than not, they result in poor organization in the long haul. A typical scenario that emerges is that a user or group of users would like to have some popular report tweaked for their particular purposes. While the customer is always right, we in BI have the responsibly to be forward-thinking and to manage these requests in a way that does not leave the customer or the BI provider with a nightmare to manage down the road. So we may end up with a scenario where we go from one master 'Accounts Receivables' report, to 2 or 3 reports representing slightly different views of essentially the same content. What is even worse than having multiple reports or cubes on essentially the same data domain is not being able to quickly and easily find and distinguish such reports. I've worked in organizations where the 2nd version of the report might have been called 'Accounts Receivables - Bob' or the 3rd, 'Accounts Receivables - New York'. What happens when “Bob” changes departments?

In a minute, I will present common and time-tested methods to avoid having to duplicate reports or dashboards for presentation to multiple audiences. But the problem still remains - how do you set up your content in an organized manner - for the short and long run? Not much rocket science: prefix your report names with a set of well-thought-out numbers. So instead of simply having 'Accounts Receivables' report, you'd have '19020 - Accounts Receivables', where 19020 uniquely identifies this report. Over time, BI users will revert to calling this report by the number, though they very well know the name!

So how do you come up with a numbering scheme for your BI content? You have two basic options, build some intelligence into the numbers or you could simply carve out ranges for particular divisions within your organization or categories across the divisions. The ranges should have some relevance to how your content is set up - whether the folder structure mimics your physical organization structure or not. I'd caution against building too much intelligence into the number, as this could back you into tight corners if you need to share content across divisions (we'll talk later about how to get around this). So what's an example of a numbering scheme?

1000 - 2999: Finance & Accounting (1,999 slots - a lot! - as these are highly analyzed corporate functions)
3000 - 3999: Engineering (999 slots)
4000 - 4999: Billing & Quality Assurance (999 slots)
5000 - 5499: Marketing (slots)

And you could set up sub-divisions under the major categories, such as:

1000 - 1099 - Accounts Payables
1100 - 1199 - General Accounting
1200 - 1299 - Budgeting

If every analytic solution - report, dashboard, cube, trigger, document in a BI system is numbered, users will have confidence that they're using or referring to the right tools to aid them in their decision making process. The area where numbering can be most helpful to users is in searching for content. Rather than searching for 'accounts receivables' and returning 4 reports that have some combination of these words in the title or description, they can simply type in the report number and find the only object with that number. This numbering system is also useful when the actual report is not known or to acquaint a new area user with the reports available to their department or group.

A numbering system is invaluable for BI Administrators and developers as well. For Administrators, the code repository outside of the BI Platform could be set up to match the numbering structure. When a new report / dashboard comes in, the first task is to create folder in the code repository for this deliverable using a newly assigned number. Once the task is assigned to a BI developer, she/he would know where in the code repository to go to start on their assignment. The developer would create their analytic solution - as well as all supporting documentation - using the newly assigned number.

So how do you avoid duplicating content to satisfy different business audiences? There will be requests to clone reports or other analytics for different audiences, resulting in a massive number of objects to maintain, all with practically the same logic. The easiest way to get around this is to use row and column-level security wherever possible. In order to have the widest impact, this should be done at the semantic layer level (Universe, Business View) whenver possible . Another technique that should always be used is incorporating dynamic parameters or prompts that drive users to make selections that affect what columns and/or rows get displayed in their favorite analytic solutions. In this case, parameters and prompts also serve to circumvent requests for cloning reports by allowing users to create a more personalized report.

Voila! A simple strategy for helping you manage BI content. I wish I could take credit for this idea - I learned it many years ago from a buddy, an ex Airforce Avionics Engineer, who applied his wealth of military experience whereever he went. Thanks, Nick!

Read 4490 times Last modified on Wednesday, 22 April 2015 09:28
Will Munji

Will Munji is a seasoned data integration, data warehousing and business intelligence (BI) architect & developer who has been working in the DW/BI space for a while. He got his start in BI working on Brio SQR (later Hyperion SQR) and the Crystal Decisions stack (Reports, Analysis & Enterprise) and SAP BusinessObjects / Microsoft BI stacks. He currently focuses on Talend Data Management Suite, Hadoop, SAP BusinessObjects BI stack as well as Jaspersoft and Tableau. He has consulted for many organizations across a variety of industries including healthcare, manufacturing, retail, insurance and banking. At Kindle Consulting, Will delivers DW/BI/Data Integration solutions that range from front-end BI development (dashboards, reports, cube development, T-SQL/ PL/SQL ...) to data services (ETL/ DI development), data warehouse architecture and development, data integration to BI Architecture design and deployment.

Leave a comment

Make sure you enter all the required information, indicated by an asterisk (*). HTML code is not allowed.

Contact Us

Kindle Consulting, Inc

6595 Roswell Road 
Suite G2025 
Atlanta, GA 30328

Phone: 404.551.5494
Fax: 404.551.5452
Email: info@kindleconsulting.com

Talend Gold Partner