Design Challenge

Imagine you are a data analyst on a highly motivated business intelligence (BI) team about to start phase 1 of an enterprise data warehouse. The IT side, including analysts, modelers, developers and testers, all have the experience and motivation to make the project a success. There is a business sponsor funding the project who is also ensuring the necessary business involvement. There is just one obstacle: the business folks involved lack the knowledge of their own business. This might sound unbelievable, but due to high turnover on the business side and short training cycles, the businesspeople might know what to click on a screen and what actions to take when certain business events occur. However, most do not understand why they are doing what they are doing.

The Challenge

As the data analyst, you need to capture how the organization works and the detailed reporting requirements. What techniques would you use when you have business-side involvement that lacks business expertise?

The Response

We need to first validate the observation that the business truly lacks business expertise. If this perception is reality, the analyst can decide to continue to work with the business, lean on IT or look outside the organization.

Don’t Give up on the Business

There could still be very valuable business resources in the form of both people and documentation that can allow the analyst to capture how the business works. John Ladley, consultant and industry lightning rod, recommends talking with the HR department about what they need to accomplish, reviewing financial documents such as annual reports for core metrics and meeting with the business to find out how they use industry benchmarks. Carol Lehn, senior data engineer, suggests the analyst meet with more senior businesspeople who have worked their way up through the ranks and have a lot of the business knowledge and background to fill in many of the details the current business users don’t have. Lehn says, “More often than not, they’re happy to share what they know, even if it’s outside of their current sphere of responsibility.”

Lean on IT

The analyst can also talk with IT resources or dive into existing operational and reporting systems. Several design challengers suggested “reverse engineering” source systems into logical and conceptual models as a good step toward learning how the business works. Pat Henaghan, data manager, summarizes this approach: “IT analysts/developers should develop a narrative for the programs, showing inputs, outputs and processes applied. When presented with the processes and outcomes, the business community then has a starting place to work through the business rules. They may not know their business, but they likely have some preconceived notions of what their work is. When they learn what the programs are doing, they may react by arguing that the process is incorrect. Nonetheless, it is what it is. They then can begin to refine the narrative to develop the business rules and learn their own business.”

Both Anne Huey, data analyst, and Bob Schork, data modeler, would recommend the analyst see what the underlying systems do before and after a button push to identify how the data changes. This can help with capturing both a data and process view of the world through the eyes of the application. Tom Faulkner, data analyst/modeler, suggests leveraging IT employees. Faulkner says, “Lots of times the IT people in an organization know more about the business rules than the businesspeople do. Talking with the business and with IT helps to piece together the puzzle of why things are done a certain way.”

Look Outside

My first reaction to this challenge would be to look at industry practices to build the initial model of the business. Industry standard models and enterprise resource plann- ing documentation are two excellent sources. Akhtar Ali Khan, information architect, also recommends looking at other companies in the same business to understand how they operate and then relating the findings to this organization.

A combination of these techniques might be necessary for the analyst to capture the complete picture. There are other creative approaches as well. Barbara McCuaig, data modeler, has this suggestion for the analyst: “Shadow the business user as they perform their day-to-day tasks. In this way you would see the events, the processes, the screens and the reports. This would give you a very good start in identifying the required data and how it’s used.”

If you would like to become a design challenger and have the opportunity to submit modeling solutions, please add your email address at http://www.stevehoberman.com/. There is also an overview on how to read a data model at http://www.stevehoberman.com/.