Perhaps it’s just coincidental, but several people have asked a similar question recently. “Should the DW or BI team gather requirements from the business?” Honestly, this question makes the hair start to stand up on the back of my neck. I’m concerned that too many organizations have overly compartmentalized their data warehouse and business intelligence teams. Of course, […]
Design Tip #64 Avoid DW/BI Isolation
Perhaps it’s just coincidental, but several people have asked a similar question recently. “Should the DW or BI team gather requirements from the business?” Honestly, this question makes the hair start to stand up on the back of my neck. I’m concerned that too many organizations have overly compartmentalized their data warehouse and business intelligence teams.
Of course, some of this division is natural; especially when the resources allocated to DW/BI grows as the environment expands, creating obvious span of control issues. Also, separation of labor allows for specialization. Viewing the overall DW/BI environment as analogous to a commercial restaurant, some team members are highly-skilled in kitchen food preparation while others are extremely attentive to the needs of the restaurant patrons, ensuring their return for a subsequent visit. There are likely few waiters that should suddenly don the chef’s garb, and vice versa.
Despite the distribution of responsibilities, the kitchen and front rooms of a restaurant are tightly entwined. Neither can be successful on its own. The best chefs need a well-trained, well-oiled front room machine; the most attractive dining room requires depth and quality from the kitchen. Only the complete package can deliver consistent, pleasurable dining experiences (and sustainability as a restaurant). That’s why the chef and wait staff often huddle to educate and compare notes before a meal rush.
In the world of DW/BI, we’ve observed some teams take a more isolationist approach. Matters are further complicated by the complexities and realities of organizational culture and politics. There may be a kitchen and dining area, but there’s no swinging door between the two. It’s like there’s a transom (above eye level) where orders and plates are flung back and forth, but the two
teams of specialists aren’t communicating or cooperating. In this scenario, you end up with data models that can’t reasonably be populated. Or data models that don’t address the diners’ needs and/or leverage their tools. Or diners’ tools that are overtaxed or slow-performing because they’re repeatedly doing the work that could have been done once in the kitchen and shared throughout the organization. In the worse case, the wall becomes so impenetrable that the BI dining room substitutes a different kitchen (or creates their own) to source meals.
The data warehouse should be the foundation for effective business intelligence. Too many people have focused on one without the other. Sure, you can create a data warehouse without concern for business intelligence, and vice versa, but neither situation is sustainable for long. Isolationism is not a healthy approach for building and supporting the DW/BI environment. Even if you don’t report into the same management structure, collaboration and communication are critical.
It’s not unusual to identify dozens of different dates, each with business significance that must be included in a dimensional design. For example, in a financial services organization you might be dealing with deposit date, withdrawal date, funding date, check written date, check processed date, account opened date, card issued date, product introduction date, promotion begin date, customer birth […]
Do you know the difference between dimensional modeling truth and fiction? According to Merriam-Webster, fables are fictitious statements. Unfortunately, fables about dimensional modeling circulate throughout our industry. These false claims and assertions are a distraction, especially if you’re trying to align a team. In this column, we’ll describe the root misunderstandings that perpetuate these myths so […]
Business acceptance is a bigger problem than BI/DW professionals want to admit. Here’s how to get on the right track. A recent Data Warehouse Designer column, “Data Warehouse Check-Ups” (June 12, 2004), discussed the importance of regularly casting a critical eye over your data warehouse/business intelligence (DW/BI) program. Check-ups identify early warning signs and symptoms so appropriate […]
In this Design Tip, we return to a fundamental concept that perplexes numerous dimensional modelers: text facts (also referred to as fact indicators, attributes, details or notes). Some of you may be rightfully saying that text facts are a dimensional modeling oxymoron. However, we frequently field questions from clients and students about indicator, type or comment fields that […]
Periodic check-ups will help you avoid letting business intelligence and data warehousing problems spin out of control. It’s human nature to resist visiting a doctor for periodic check-ups. Generally, we’d prefer to avoid being poked and prodded, having our vital signs taken, and then being told that we need to quit smoking, exercise more, or […]
As with most things in life, change is inevitable with dimension attributes. Most Design Tip readers are familiar with the three basic slowing changing dimension (SCD) techniques: Type 1: Overwrite the attribute Type 2: Add another dimension row Type 3: Add another dimension attribute If this is news to you, take a look at Ralph’s April […]
When developing dimensional models, we strive to create robust dimension tables decorated with a rich set of descriptive attributes. The more relevant attributes we pack into dimensions, the greater the users’ ability to evaluate their business in new and creative ways. This is especially true when building a customer-centric dimension. We encourage you to embed intellectual capital in […]
The Kimball bus architecture and the Corporate Information Factory: What are the fundamental differences? Based on recent inquiries, many of you are in the midst of architecting (or rearchitecting) your data warehouse. There’s no dispute that planning your data warehouse from an enterprise perspective is a good idea, but do you need an enterprise data […]
I worked at a company called Metaphor back in the early 1980s. As part of a startup software company introducing then-cutting-edge concepts (such as folders, file drawers, and workflows on a graphical electronic desktop), I appreciated the benefits of using metaphors to represent seemingly complex concepts. Effective verbal and visual metaphors are able to convert complexity into […]