Q: Our company provides reporting capabilities to its clients with different needs. What is a potential approach to provide these clients performance reports customized to their needs? The volume of data the company deals with overall is substantial. We currently provide "client data marts" when the data size dictates it; separating their data. This is usually driven by the performance of their reports. Is this a sensible approach?

Sid Adelman's Answer:

It will depend on how much the data overlaps. If the data for each of your clients is totally independent of the data for your other clients, it makes sense to keep each client data mart separate. If the data does overlap, then the degree of overlap should help determine your solution. Security requirements could also drive you to keep the data separate, especially if you let the clients create their own queries and reports. If you charge back to the clients, you would also want to keep their data separate.

Chuck Kelley's Answer:

I think this is a very common way to deal with this issue.

Evan Levy's Answer:

That is a very sensible approach! I like to remind my clients that the success of data warehousing isn't just the volume, accuracy, and accessibility of data, but the usability of the data content. From your remarks, it appears that you provide your users a high degree of flexibility by providing them standard reports as well as the data content. This approach allows the users to build anything custom from a reporting perspective that they can imagine.

I whole heartedly agree with providing data to experienced business users when standard reports aren't sufficient. However, I recommend that my clients proceed cautiously in providing data to their users.Some of the recommendations I make include:

  • Keep the data that you provide to them simple and well defined. Focus on standard business defined data elements and stay away from any custom calculations.
  • Stay away from supporting any "custom ETL" processing. Provide the users with a standard, well-defined file. Be prepared to provide them support for each data element - as in providing data lineage.
  • Stay away from supporting their custom database designs. You support the data, not an unknown or unique database design.

Tom Haughey's Answer:

I believe it is but there are some other alternatives.

First is a self-service architecture. In this, the data is put in place and published but it is up to the business community to build the applications. I am not in great favor of this architecture but it is one that many people talk about. In the self-serve architecture, business pulls the data it needs. The conventional approach is that IT develops applications and the DW pushes the data. The theory behind the self-service architecture is that the business is less dependent on IT for developing applications. The DW team can focus on optimization of data storage and data delivery to applications. The business can develop the applications they need. The theory is that this reduces the need to translate requirement because the business originates them. There are some serious fallacies with this approach. The implication is that IT and the business have different levels of involvement. I contend they have the same involvement but the placement of these involvements has shifted. IT is still needed to develop these capabilities, even if it an IT organization is within the business area. Business people do not develop IT applications. Besides, even in the conventional approach, IT does not just develop these applications without the aid of the business. Consequently, the business must be equally involved in either approach; and equally, there is some translation of requirements in either approach.

Second, data marts, as you describe are an answer. Because they are customized, there is a separate and significant cost associated with them.

Third, providing a rich set of generalized or intermediate aggregates that all users can utilize can help. Instead of users going against the base grains of the DW, they can go against pre-aggregated data. This will be more efficient than the base grains, but not as efficient as customized data marts. These can be considered embedded data marts.

Fourth, construct a reporting subsystem. There are many ways to do this. One way is a reporting subsystem with templates. This is effective but is costly to create, though it is a one-time cost. This allows users to create their own reports instantaneously without having sophisticated skills, and to even create ad hoc reports without being power users. Some products, such as Crystal Reports, had a built-in template facility called CI Desk. An alternative to a template-driven reporting subsystem is a generalized reporting subsystem. I have seen IBM do this for several customers. They built a generic reporting capability in Java that was easy to use, driven off the catalogue, supported all data in the database, and that provided robust reporting capabilities at a comparatively minimal cost. This was a very effective solution. Its main disadvantage is that it is custom code, though in this case I think it is a viable solution, and it was comparatively cost-effective.

Register or login for access to this item and much more

All Information Management content is archived after seven days.

Community members receive:
  • All recent and archived articles
  • Conference offers and updates
  • A full menu of enewsletter options
  • Web seminars, white papers, ebooks

Don't have an account? Register for Free Unlimited Access