Roadmap to the Data Gateway (Part 2 of 2)

>>>Roadmap to the Data Gateway (Part 2 of 2)

Editor’s note: Last week we brought you the first half of the “Roadmap to the Data Gateway” post. If you missed it, you can find it here. During this post we defined the “Who”, “What” and “How” of roadmap development. Now, we will learn how to bridge the gaps between the Business and BI teams, proper tool selection, and merging all the data together into one central repository.

Often times, we find that clients have taken a less than holistic approach in order to integrate high-demand reporting requirements with quick turn-around requests over the years, yielding collections of redundancy and inconsistency across multiple lines of business.

After juggling the queue of requests, rearranging priorities, and determining turnover dates, the user community submits to creating its own reporting solutions such as intelligent, but non-collaborative data spreadsheets. More and more, power users pursue creative methods of individualized reporting, which, in the end, result in multiple versions of the truth. Both the Business and BI teams lack the resources to enforce standardization.

The goals of both teams are the same. They strive for excellence and work toward providing the company with the tools needed to be successful. Recognizing the need to blend both teams together, along with all other stakeholders, into one, equal team with one common goal; project success, is a success determinant.

Of course, signed-off requirements documents clearly written and examined are also a must before development begins. These should define the parameters for standardized reporting requirements that have been vetted by all stakeholders. During this phase and throughout the development lifecycle, complete transparency is paramount.

In order to bridge any language gaps between the BI and Business teams, tools should be set up to ensure complete understanding. For example, where requirements appear vague to the BI team, it should draw up a series of spreadsheets or mockups to run through its understanding and collaborate with the Business prior to developing the solution.

Time should also be allocated to the BI team to provide design and mappings documentation to the Business community throughout the project. The Business is the BI team’s advocate with its primary interest in ensuring its requirements are being met.

Selecting the most suitable visualization tool(s) is a checklist process where each tools’ functionality should be matched to the requirements carefully. For real-time reporting, the ability to cache result sets into memory (in-memory caching) and remain accessible by future end-users reduces report refresh time. Dashboards and scorecards empower users to create easy to follow and manipulate story boards. In addition, these analysis tools create an atmosphere of near-instant discovery by allowing the users to drill up and down dimensions as well as across dimensions. Additional capabilities include the ability to manipulate data on the fly for the purposes of predictive analysis.

A central theme prior to releasing self-service exploration and analysis tools is education. Training must take place to prevent issues such as the following:

1. Improper end-user report and dashboard designs may overload your production environment resulting in loss of availability or very low performance. This includes creating a report where there are no limitations on the number of rows a report returns.

2. With a company-wide standardized reporting directive, end-users must be aware of the new business rules. Otherwise, while much of the new business rules are enforced in the design, the users are likely to find ways around them inadvertently. Over time, the company may find itself back in the same position of having one too many creative methods to answer the same question resulting in variations. Likewise, the BI team must be well-versed so that it alerts the requestors of non-compliance.


Several user-produced solutions have been created of data dumps intelligently manipulated by a variety of methods including pivot tables, macros, and spreadsheet data analysis tools. The process for extracting pieces of information from multiple sources, transforming it into relevant data and staging it into a presentable format is time-consuming and error-prone.

No longer should this be the case upon unveiling the new reporting solution. The BI team has the information and tools necessary to drive toward its goals of delivering a Gateway Power-House, allowing the Business community to consistently explore its universe of data with far less restrictions. Now, the team needs to bring it all together into one central repository as illustrated below.


The team identified the need to build a new data warehouse (DW). In the course of examining the requirements, it created a “source to target mapping” document detailing sources of all critical pieces of information. Among the most critical pieces in the suite of documentation, it has also created a data flow diagram for a more visual overview of the source to target processes.


Figure – Simplistic Example of the Data Flow Diagram

End-user technical training plans have been applied. The Business has reinforced the necessity to adhere to universal standards. The end-users are now ready to apply their strategies in the newly deployed Gateway environment giving the users the tools to align the company to its goals.

Angel S. Kahmar is a Senior Consultant at SDLC Partners, a leading provider of business and technology solutions. Please feel free to contact Angel at with any questions on this blog post or to further discuss Business Intelligence.