Living on both sides of any issue helps you appreciate why each side firmly defends its respective position.
The ongoing debate between database marketers and information technology professionals regarding data warehouses and database marketing systems lives today for a variety of reasons. I have spent intimate time with both camps and can help illuminate the position for each viewpoint.
This debate is more than 10 years old. Perhaps some background on each side is in order, since history often lends perspective.
The concept of data warehousing actually dates back more than 25 years to Massachusetts Institute of Technology research on the requirements of analytic processing versus transaction processing. In conjunction with IBM research, it helped spawn the Information Center movement of the 1980s. These systems were — and continue to be –conceived and designed by information technology departments. Although arguably their objectives have evolved, initially they were aimed at removing the heavy impact of analytic and ad hoc report processing on production transaction processing systems.
As this field matured, better designs were instituted that met the unique performance requirements of analytic processing. Yet, the term and spirit of data warehousing stuck. As the name suggests, the goal was to get data from production systems into an organized “warehouse,” where it could be efficiently standardized, stored, tracked and sorted.
At the onset, no one placed any great emphasis on how to most effectively deliver this information to the ultimate customer. In fact, one of the biggest pitfalls of this movement was that the customer was loosely identified as the “enterprise.”
Meanwhile, in the mid to late 1980s, the importance of marketing and customer centricity began to escalate and with it the need for dynamic customer information. Data warehouses were in their infancy, if existent at al. Information centers were ill-equipped to handle an inundation of sophisticated ad hoc marketing information requests, and instead were designed to handle primarily pre-defined reporting requests. Not coincidentally, third-party vendors noticed this opportunity and solicited early adopter marketing departments to build, house and manage their marketing databases.
The two met in the realm of the data mart. Data warehouse proponents suggested a “marketing data mart” could meet the unique marketing requirements. Database marketers studied the definition of a data mart and found enough leeway to accept this as a moniker. Many corporations moved from hosted systems and embarked on building some form of a marketing data mart in hopes of alleviating some of the disadvantages of the outsourced model.
So we come to today, and the current question: So what is the difference and is it just semantics? It depends on how your environment has been constructed. So you will need to compare your systems to these characteristics:
Data Warehouse
· Central hub for ETL (extract/transform/load), standardization, staging and switching of data from legacy systems to other decision systems.
· Designed to store enterprisewide decision data, not just marketing data.
· Though data is grouped in subject areas, there may be no specific data subject area centricity. Instead, design may be more normalized to minimize redundancy and simplify maintenance for staging and historical layers.
· Generally read-only from the end-user's standpoint.
· Time variance and nonvolatile design is strictly enforced. Simply put, this translates into copious amounts of incremental changes being preserved to keep history in tact even though there may not be a specific/current requirement for this data trail.
Marketing Database
· Customer-centric design using customer/prospect centric facts and noncentric dimensions such as time, products and geography.
· Key customer data, including various third-party data, are appended and scrubbed for customer delivery via multiple channels (e.g., postal data standardization for direct mail delivery).
· Merge-purge routines consolidate records, performing house-holding and business matching.
· Promotion history and campaign management data are immediately written to the database.
· Since campaign management functionality is not supplied by generic ad hoc query and reporting tools (e.g., campaign control cells, splits, hierarchies, ranking, scoring, scheduling, etc.), specialized tools are added to supply these features.
· Dynamic scoring and segment tagging routines require access to detailed customer transaction records. Online analytical processing consolidated cube data generally will not suffice.
· Marketing's data consolidation, retention, reporting and performance requirements may be different from other departments.
· Complex extract and data propagation requirements to move customer data to/from channel touch points.
· Loyalty program administration.
Data Mart
· Subject area specific. Generally have been departmental or functional in nature (e.g., finance mart, marketing mart, human resources mart).
· Dimensional modeling and star schema design employed for optimizing performance of access layer.
· Transaction data — regardless of grain — fed directly from data warehouse (there is really no such thing as a data mart without a data warehouse).
· Usually includes consolidation data structures not found in data warehouse to meet subject area's query and reporting requirements.
If you buy into the above definitions, a data warehouse appears to be a unique entity, born and raised by IT. Its purpose in life is to act as an integrated single point of enterprise decision data distribution — a noble and useful, though not easily attainable plight.
Conversely, the line between data marts and marketing databases is very blurry. If your marketing database is designed properly and tightly coupled with your data warehouse, then you probably have a marketing data mart. Yet the reverse is not necessarily true. In other words, someone may have built you a marketing data mart that is coupled to your data warehouse, yet it could be missing key marketing database functionality.
In conclusion, what is most important is not the name given to your system, but its true ability to meet current and future end-user requirements.
If marketing drives your core decision support requirements and you do not have other functional users clamoring for decision support, you may not need a data warehouse. If you have a data warehouse and a separate marketing database, you probably would benefit from an effort to join and rationalize the two, since each is probably performing similar ETL and data storage functions.
If you have a data warehouse and a marketing data mart, closely inspect the functionality of your data mart to ensure it meets all of your marketing information retrieval, analysis and delivery requirements. If you have all three, you probably have some redundant functionality.
There is at least one more system to add to the mix these days, namely a customer relationship management system.
So, do you need all four?
Precisely defining a CRM system is difficult since it should encompass requirements outside the direct scope of marketing — such as sales automation, customer service, telemarketing, Web site management, etc. However, a complete CRM system will overlap with database marketing functions, which is why most marketing database vendors now call themselves CRM providers.
So be careful, because if you are building all four as separate systems, then you will end up with a lot of overlapping features that will cause confusion.
