In my last article, Sivad was provided a data access layer to the raw data and now has the ability to grab the data and use it in the Dashboard Application. Now we’re at the part where we manipulate (“massage”) this data so it’s easy for the User Interface to consume.
In Part 2, Davis’ database team provided the following data sets back.
For the Daily Sales Revenue
:
For the Sales Revenue for the Rep by Month
For the Sales Revenue by State by Month
From Part 1, we wanted to show Daily Sales Revenue, Performance of Reps, and Revenue by US State. What’s nice about the data returned is we can show summations for each respective metric. E.g. we can show the Sales Revenue Trend, and we can show the Total Sales Revenue from the chosen time range as depicted below.
If Davis decides he would like to see the total sales for a particular time range, the business logic would handle the calculation, rather than going back to the database. Normally, the business logic will handle the following calculations:
- Aggregating Trends to a Total Sum Metric
- Calculating averages
- Color coding with regards to heat maps
- Various Financial Calculations such as Moving Average, Forecasting, etc.
- Setting flags to mark a data point because of a significant event based on certain rules (e.g. if a value is over $12,000 dollars in an expense trend, it needs to be shown differently)
For Davis’ dashboard, Sivad will need the business logic to manipulate the data in the following manner
- For the Daily Sales Trend, Davis would like to compare the trend with the overall average.
- For the Daily Sales by Rep, Davis would like to compare each Reps Daily Sales with the Daily Average of all Reps.
- For the Daily Sales by State, Davis would like to see a heat map of the performance of each state by the date ranges total. Red indicates the total of that state is one std. dev. below the average of all states, yellow is within plus or minus one std. dev. of the average of all states, and green is one std. dev. above the average of all states.
Once the business logic is completed, Sivad can now focus on the user functionality; i.e. Sivad will need to determine how Davis will be able to filter and drill down on the data shown in the dashboard.
Article Summary:
In this article, we discussed the business logic aspect of the Dashboard. The business logic’s major purpose is manipulating the data in a manner that makes it easy for the User Interface to consume. When designing the architect of a dashboard implementation, it is important to separate this business logic from the user interface for the purpose of maintainability and logical flow. It’s a software development best practice, and truly applies here, as well.
Copyright 2008 - Dashboard Insight - All rights reserved.